jerry/buzz
1
0
Fork 0
mirror of https://github.com/block/buzz.git synced 2026-11-01 15:01:12 +00:00
Code Issues Packages Projects Releases Wiki Activity
2,261 Commits 1,288 Branches 247 Tags
4a283e4c5dd4ecd6dd629f9d8a2913a0fbfd146d
Commit Graph

2261 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
Duncan
4a283e4c5d fix(read-state): add GEN_REBASE_HEADROOM to prevent allocator cliff at valid near-ceiling states 
The rebase boundary was requiredNextGen >= MAX_SAFE_INTEGER (one notch), which
left a one-click cliff: a valid blob {pi.gen: MAX-2, ng: MAX-2} would hydrate
with nextGen=MAX-1, click 1 minted MAX (safe, persisted), and click 2 threw
synchronously up markChannelRead/markChannelUnread.

Add GEN_REBASE_HEADROOM = 2**32 (~4.3e9). Rebase now fires when requiredNextGen
>= MAX_SAFE_INTEGER - GEN_REBASE_HEADROOM, guaranteeing at least GEN_REBASE_HEADROOM
allocations succeed after any hydration. allocateGeneration()'s throw is
unreachable from any valid persisted state and remains defense-in-depth only.

Restructure drainPendingIntents so the finally block clears drainScheduled
unconditionally, and the success-path bookkeeping (counter reset + pendingFreshDrain
chaining) runs AFTER the try/finally block. Previously the success path set
drainScheduled=true for the chained drain inside the try, then the finally
overwrote it with false, silently cancelling the chained drain's guard.

Update Test 60 to use the MAX-2 starting state (Paul's exact repro). Add
Test 62 as the control witness: a normal blob (gen=1000, ng=1001) hydrates
verbatim with no rebase, proving the headroom trigger does not fire on healthy
state.

Co-authored-by: Will Pfleger <pfleger.will@gmail.com>
Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
 2026-08-08 19:55:07 -04:00
Duncan
0d7fe32a9e fix(unread): centralize allocateGeneration, fix rebase boundary, add finally to drainPendingIntents 
Round-8 fixes for #3966:

1. allocateGeneration() primitive (pendingOverrideIntents.ts)
   Preflights BOTH the emitted gen AND _nextGen+1 before any mutation.
   If either is unsafe, throws without touching any queue/transaction map.
   Replaces both post-increment isSafeInteger guards in enqueue() and
   promoteDeferred(). promoteDeferred() now allocates FIRST, then mutates
   deferredEnqueues/promotedDeferredPayloads — so an allocation failure
   leaves the deferred payload untouched and abortTransaction can safely
   re-buffer it.

2. Hydration rebase boundary (readStateStorage.ts)
   Condition order swapped: rebase checked before clamp. New trigger:
   !isSafeInteger(requiredNextGen) || requiredNextGen >= MAX_SAFE_INTEGER
   This catches maxObservedGen = MAX_SAFE_INTEGER-1 (requiredNextGen =
   MAX_SAFE_INTEGER), which previously passed the isSafeInteger check and
   took the clamp path, leaving nextGen=MAX_SAFE_INTEGER and one tick from
   poisoning _nextGen. Added isSafeInteger guard to ng serialization.

3. Promotion allocation failure → total-closure exit (readStateDrain.ts)
   promoteDeferred() call in step-3 is now wrapped in try-catch. If
   allocateGeneration throws, the catch calls abortTransaction +
   scheduleAbortRetry and continues, same as other non-success exits.

4. drainPendingIntents finally (readStateManager.ts)
   Wrapped in try-finally so drainScheduled=false always clears, even on
   an escaped exception from the impl. Condensed JSDoc for scheduleDrain
   to stay within the 1000-line ratchet.

5. Two new witnesses (Tests 60, 61):
   - Test 60: pi.gen=MAX-1, ng=MAX-1 → hydrate → rebase fires → two
     enqueues get safe distinct gens, neither throws, persisted ng safe,
     both intents survive fresh-manager hydration.
   - Test 61: _nextGen forced to MAX_SAFE_INTEGER via restoreFromStorage
     with deferred gen2 mid-transaction → drain → allocation throws in
     promoteDeferred → catch routes to abortTransaction+scheduleAbortRetry
     → drainScheduled false, drainRetryTimer set, gen1 live, deferred
     payload preserved → hydrateFromLocalStorage normalizes _nextGen to 2
     → retry drain completes gen1+gen2, frontier ≥ 999.

Optional MINOR (explicit typed pass outcome): skipped. The change would
require threading a return value through drainPendingIntentsImpl and its
caller, adding several lines to files already near the ratchet. The current
drainRetryTimer === null discrimination is sound for the synchronous impl.

Co-authored-by: Will Pfleger <pfleger.will@gmail.com>
Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
 2026-08-08 18:40:08 -04:00
Duncan
da0461a090 fix(read-state): close round-7 acceptance failures — backoff, ng clamp, 5 witnesses 
Paul's round-7.5 dispatch (unreviewed SHA: 4002067de3):

1. Backoff escalation dead code fixed: move drainRetryAttempt=0 reset inside the
   success branch (drainRetryTimer===null after impl, i.e. no abort was scheduled).
   Previously reset unconditionally on every pass return, so attempt stayed at 1
   forever; escalation 1s→2s→4s…60s now engages on repeated failures.

2. ng=MAX_SAFE_INTEGER clamp-down: normalization now also clamps nextGen DOWNWARD
   when parsed ng exceeds max(valid intent gens, valid receipt gens)+1.  Previously
   raised nextGen only; a corrupt ng=MAX_SAFE_INTEGER with low intent gens left
   nextGen=MAX_SAFE_INTEGER, causing first enqueue to mint gen=MAX_SAFE_INTEGER and
   the second enqueue to throw from the isSafeInteger guard.

5 new witnesses (Tests 55-59):
   - Test 55: fake-scheduler, step-1 failure held across ≥2 timer firings; asserts
     drainRetryTimer IDs (not first-scheduled entry) for delay 1s then 2s; verifies
     attempt counter preserved across aborts and reset to 0 on success.
   - Test 56: same-channel stale-receipt collision at MAX_SAFE_INTEGER ceiling —
     ng=MAX_SAFE_INTEGER triggers rebase; replacement enqueue gets gen above all
     retained receipt gens; frontier reaches 999.
   - Test 57: ng=MAX_SAFE_INTEGER multi-enqueue — clamp-down fires; two enqueues
     both receive safe distinct gens; both survive subsequent hydration.
   - Test 58: thrown-handler witness — onDrainOutcome throws; transaction aborts;
     gen1 restored live; bounded retry timer at 1s; next enqueue gets real gen (not
     deferred placeholder), proving channel unlocked.
   - Test 59: identity-swap — A deferred mid-transaction, B hydrates; B's enqueue
     gets real gen and correct op (A's payload did not leak via clearTransactionState).

Co-authored-by: Will Pfleger <pfleger.will@gmail.com>
Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
 2026-08-08 17:32:15 -04:00
Duncan
4002067de3 fix(read-state): close round-7 findings — bounded abort retry, gen exhaustion, total tx closure 
Round 7 fixes for PR #3966 (Thufir's BLOCKED verdict at 35873afea3):

1. Bounded drain-retry controller: scheduleAbortRetry() gives abort retries
   their own escalating timer (1s→2s→4s…60s), coalesced per manager, cancelled
   on destroy() and identity change. Abort paths call scheduleAbortRetry(); only
   the success-path gen2 promotion uses scheduleDrain() (immediate). No microtask
   spin loop under persistent storage failure.

2. Generation exhaustion without reuse: deleted nextGen=1 ceiling reset.
   Hydration now compacts/rebases all pending intent gens and their matching
   receipt gens into a fresh safe range [1..N] when maxObservedGen is at or
   above MAX_SAFE_INTEGER; nextGen = N+1 after rebase. Both enqueue() and
   promoteDeferred() guard the _nextGen++ with Number.isSafeInteger(gen).

3. Total transaction closure: onDrainOutcome wrapped in try/catch — thrown
   callback triggers the same receipt-aware abortTransaction + scheduleAbortRetry
   path as the storage-failure abort, not a silent latch-forever exit.
   restoreFromStorage() clears all transaction-only maps (clearTransactionState)
   so no lock/snapshot/deferred/promoted state survives an identity swap.
   destroy() calls clearTransactionState() for the same reason.

4. Witnesses to contract (Tests 51/52/37):
   - Tests 51/52: enqueue gen2 from onDrainOutcome (isLoadComplete toggle forces
     deferred latch path); fail exactly one write; let real bounded scheduler fire
     retry (no manual intercept); assert intermediate blob, recovered combined
     gen1-cleanup+gen2-pi commit, restart parity.
   - Test 37: Phase 5 sends TWO reconnects while gen-2 held; Phase 6 releases
     secondBarrier, asserts gen advances to gen1+2, fetchCallCount=3 before
     destroy. All assertions unconditional.

Co-authored-by: Will Pfleger <pfleger.will@gmail.com>
Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
 2026-08-08 16:26:45 -04:00
Duncan
35873afea3 fix(read-state): close round-6 findings — abort/retry, gen hygiene, production handler 
Round-6 fixes for NIP-RS unread state (#3966):

1. Transaction abort/retry on failed cleanup writes

   abortTransaction() on both step-1 (register+receipt persist) and step-3
   (cleanup persist) failure paths: gen1 is restored as the live intent,
   any promoted gen2 is re-buffered into deferredEnqueues, and scheduleDrain
   fires a retry pass.  Promotion only happens inside a successful commit —
   durable gen1 and in-memory gen2 can never silently diverge.

   Retry mechanism: scheduleDrain() after abort, which fires
   pendingFreshDrain handling in drainPendingIntents (immediate re-drain
   in the same session; restart recovery handled by Amendment C receipts).

   Failure semantics on step-3: gen1 register is already durably committed
   (step-1 succeeded).  The receipt is restored in-memory so the retry
   drain's alreadyApplied check fires (cleanup-only, no re-bump).
   The v2 blob retains gen1 pi+receipt until the cleanup write succeeds.

2. Generation hygiene

   Number.isSafeInteger() checks everywhere (pi.gen, receipt intentGen,
   ng).  nextGen normalized to max(intent gens, receipt gens) + 1 on
   hydration, preventing a corrupt ng from reusing an existing generation
   (which would cause an old receipt to silently discard a fresh action
   via the Amendment C already-applied check).  If the increment would
   overflow MAX_SAFE_INTEGER, falls back to a fresh safe value.

3. Production drain outcome handler extracted from hook

   createDrainOutcomeHandler() extracted as a pure typed function in
   useUnreadChannelsHelpers.ts.  useDrainOutcomeCallback delegates to it.
   Tests import createDrainOutcomeHandler directly — no hand-copied mirror,
   no decorative drift guard.

Tests (4762/4762 pass):
- Tests 51/52: timing fixed — scheduleDrain intercepted to prevent the
  abort-path auto-retry from running before intermediate blob assertions;
  blockV2Writes persistent flag used for step-1 failure so both the
  initial throw and any recovery retry fail; manual retry fired after
  assertions.  Both branches covered with restart witnesses.
- Test 53: collision case (pi.gen=7, receipt gen=7, ng=7) — nextGen
  normalizes to 8+, fresh action gets gen > 7, old receipt does not match.
- Test 54: scalar-number priorForcedEntry accepted as valid legacy entry.
- Tests 45/46/47/50: now use createDrainOutcomeHandler from production.

Co-authored-by: Will Pfleger <pfleger.will@gmail.com>
Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
 2026-08-08 14:57:59 -04:00
Duncan
b4c0662fce fix(readState): round-5 v4 conformance — durable latch commit, tagged parse, overflow liveness, behavioral witnesses 
Finding 1 (durable latch commit + fresh drain):
- pendingOverrideIntentStore.promoteDeferred() called BEFORE step-3
  persistLocalState() in drainPendingIntentsImpl, so gen1 cleanup and
  gen2 pi/ng land in one v2-blob write.
- scheduleDrain() called after a successful cleanup write when gen2 was
  promoted, so gen2 drains immediately (fresh pass) rather than waiting.
- scheduleDrain() sets pendingFreshDrain when drainScheduled=true (in-
  progress drain); drainPendingIntents() honours it after the impl returns.
- Failure semantics: gen1 register already durable; if the cleanup write
  fails, orphaned receipt is swept on restart (receipt prevents re-bump);
  gen2 (if promoted) stays in-memory and drains this session.
- commitTransaction() is now a no-op unlock when promoteDeferred already ran.
- Tests 30/33 rewritten to assert the new durable contract: v2 blob has
  gen1 register + gen2 pi atomically; restart hydrates gen2; auto-drain
  fires a second pass; queue empty after auto-drain.

Finding 2 (tagged parseForcedUnreadEntry):
- Return type changed to { ok: true; value: ForcedUnreadEntry | undefined }
  | { ok: false } — null is valid legacy v1 data, not a failure sentinel.
- Structured entries rejected when ANY member of sources is invalid (no
  silent partial filtering).
- Caller updated to use parsedPrior.ok / parsedPrior.value.
- Tests 48/49 added: legacy null prior hydrates correctly; corrupt fields
  (readTarget=1e300, invalid marker=-1, invalid source member) rejected
  without blocking valid sibling intents.

Finding 3 (overflow liveness re-evaluation):
- In markChannelReadDirect, when newC > 0xffffffff, re-evaluate
  isOverrideActive(reg, effectiveFrontier) post-advance.
  Inactive → already_inactive (maps to silent-inactive outcome, source
  cleanup runs). Still active → genuine uint32_overflow refusal.
- Restores parity with sync applyOverrideRead() at readStateOverride.ts.
- Test 50 added: {s:0xffffffff,c:0,b:50} + readTarget=100 → frontier
  advanced, register deactivated, silent-inactive outcome, forced owner
  removed, versionBumps=1.

Finding 4 (cross-layer behavioral witnesses):
- wireDrainCallback() harness mirrors production useDrainOutcomeCallback
  with drift guard (exhaustive switch default assigns outcome to never).
- Tests 45/46/47 assert forcedUnreadStore (durable) via wireDrainCallback:
  45: inbox removed, manual remains, v2 blob register+C-bump, no pi/receipt.
  46: silent-inactive removes inbox from persisted forced store, versionBumps=1.
  47: full localStorage round-trip; post-restart drain; forcedUnreadStore
      restored to priorForcedEntry byte-for-byte via deepEqual.
- Tests 30/33 assert v2 blob bytes, restart hydration, auto-scheduled
  fresh drain (see Finding 1).
- Test 37 (reconnect): unchanged from round-4 — fake scheduler fires timer,
  proves second fetch, reconnect coalescing, destroy-cancellation.

File-size ratchet: readStateManager.ts trimmed to 999 wc -l (1000 gate).

Co-authored-by: Will Pfleger <pfleger.will@gmail.com>
Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
 2026-08-08 13:47:40 -04:00
Duncan
da94c3e127 fix(readState): round-4 v4 conformance — deferred-enqueue latch, boundary validation, behavioral witnesses 
Non-reentrant drain transaction via deferred-enqueue latch:
- pendingOverrideIntentStore gains beginTransaction/commitTransaction; any
  enqueue() for a locked channel is buffered, not applied; commitTransaction
  flushes the buffer as the new queue entry for the next drain pass.
- drainPendingIntents wraps each channel iteration in beginTransaction /
  try-finally commitTransaction; no post-callback gen re-check or rollback
  code is needed (Amendment A holds structurally, not by compensation).
- Step-1 storage-failure rollback retained (register+receipt+publishable+
  extraSlots only; frontier advance is monotone and safe to leave).
- markChannelReadDirect: frontier advance stays before the register check
  (spec order: frontier → C-bump); for already_inactive the advance is
  correct; for step-1 failure it is idempotent on the next drain attempt.

Boundary validation on hydrated intent fields (readStateStorage.ts):
- readTarget: must be a finite integer in [0, 0xFFFFFFFF]; 1e300 or NaN
  are rejected, preventing Date.toISOString() RangeError in the drain.
- sourceScope: constrained to the ForcedUnreadSource vocabulary
  ("inbox" | "manual"); unknown strings skip the intent.
- priorForcedEntry: validated via parseForcedUnreadEntry (new helper);
  present-but-malformed values skip the intent; absent fields are fine.
- MAX_PROTOCOL_TIMESTAMP = 0xFFFFFFFF constant defined once and shared
  between the register validators and the new field validators.

Behavioral witnesses (Test 30/33 rewritten; Tests 36/36b/37/45/46/47):
- Test 30 (drain_gen2EnqueuedDuringReplay_bufferedUntilTransactionCommit):
  proves gen2 is buffered by latch mid-replay, gen1 commits cleanly, gen2
  appears in queue after commitTransaction flush.
- Test 33 (drain_compareDeletePreservesNewerIntent): uses direct
  pendingOverrideIntentStore.enqueue() in the outcome callback to simulate
  a concurrent pre-ready enqueue; asserts v2 blob has gen1 register but no
  pi/receipt, and gen2 is byte-for-byte correct in the queue.
- Tests 36/36b: fake scheduler fires timer callbacks; proves automatic
  second attempt fires with a fresh fetch after initialize() incomplete.
- Tests 45/46/47: hook/store round-trips via wireDrainCallback helper;
  45 drives markAt > partial frontier and asserts frontier advance,
  C-bump, persisted register, forced-source removal, versionBumps=1;
  46 asserts silent-inactive removes exactly the captured source from the
  persisted forcedUnreadStore; 47 asserts priorForcedEntry is restored
  byte-for-byte in forcedUnreadStore after post-restart refusal.

Co-authored-by: Will Pfleger <pfleger.will@gmail.com>
Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
 2026-08-08 12:34:22 -04:00
Duncan
f6a12809dc fix(readState): round-3 v4 conformance — typed outcomes, markAt, restart-safe rollback, auto-retry, non-reentrant drain 
Six items from Thufir's pass-2 report:

1. Typed DrainOutcome union (applied-read | silent-inactive | applied-unread |
   genuine-refusal) with exhaustive switch in the hook layer, eliminating the
   stringly-typed seam that let already_inactive fall outside both branches.

2. already_inactive emits silent-inactive outcome so the hook's source-cleanup
   callback fires; committed forced-entry ownership is now removed exactly
   rather than left stale after a successful queued read.

3. Click-time markAt threaded through applyOverrideRead → markChannelRead →
   PendingIntent.readTarget; drain advances frontier to that exact target
   before C-bump so pre-ready reads don't lose position.

4. priorForcedEntry persisted in PendingIntent (and in the v2 blob); genuine-
   refusal DrainOutcome carries it; hook uses the persisted value when the
   in-memory snapshot map is empty (post-restart rollback is now byte-for-byte
   exact).

5. initialize() ending with an incomplete verdict schedules the first backoff
   timer (1 s, then 2 s, 4 s … 60 s via retryLoad's own loop) so pending
   intents eventually drain without needing an external reconnect signal.
   New witness: initialize_incompleteVerdict_schedulesAutomaticRetry.

6. Non-reentrant outcome commit: after onDrainOutcome fires, drain re-checks
   generation; if a newer intent was enqueued inside the callback, all in-
   memory effects (register, receipt, publishable, extraSlots) are rolled back
   and the loop continues without consuming the newer intent.
   drain_compareDeletePreservesNewerIntent strengthened with zero-stale-effects
   assertion.

Also: fix noExplicitAny in readStateStorage.ts (priorForcedEntry now typed as
ForcedUnreadEntry); ratchet trimmed to keep useUnreadChannels.ts at limit.

Co-authored-by: Will Pfleger <pfleger.will@gmail.com>
Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
 2026-08-08 11:53:40 -04:00
Duncan
9212fd40b2 Merge remote-tracking branch 'origin/main' into duncan/nip-rs-unread-format 
* origin/main: (60 commits)
  feat(desktop): unify add agent flows (#5015)
  fix(buzz-agent): budget summarizer reasoning separately so it cannot starve the handoff summary (#5248)
  infra: bind development services to loopback (#4871)
  chore(release): release Buzz Desktop version 0.5.7 (#5252)
  fix(desktop): isolate relay admission tests (#5221)
  fix(desktop): externalize boot <style> to prevent Tauri CSP nonce override (#5242)
  fix(desktop): let imported and recovered identities finish onboarding (#5228)
  Recover from max-token response truncation (#5223)
  chore(release): release Buzz Desktop version 0.5.6 (#5214)
  fix(mobile): keep latest messages above composer (#4981)
  fix(sdk): preserve self-mention p tags in message and forum event builders (#4975)
  bump @tauri-apps/cli to ~2.11.4 to fix linux app icon issue (#4858)
  feat(desktop): adding rich link previews to messages (#3818)
  fix(buzz-agent): Responses reasoning summary, Anthropic display:summarized, ACP v2 messageId (#5195)
  fix(desktop): retain distinct agent instances in autocomplete (#5202)
  fix(desktop): defer channel visibility change to Save (#5203)
  feat(desktop): Projects follow-ups — access restrictions, fast loading, activity feed polish (#5073)
  refactor(cli): replace probe/decider/detail split with single typed extractor (#5191)
  fix(desktop): drop unhandled rejection from throwing window.Notification (#5143)
  fix(desktop): fence localStorage SecurityError from killing the React tree (#5142)
  ...

Signed-off-by: Duncan <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz>
 2026-08-07 19:44:54 -04:00
Duncan
bd2ea9a5fe test(readState): complete witness inventory — production-path Amendment C, hook-level pre-ready, storage_failed, deferred-refusal 
Final witness completions for Thufir pass-2 verification:

1. Amendment C witnesses now use real fetchAndMerge() load path:
   - drain_crashAfterAppliedUnread_newerRemoteRead_noRebump: delivers the
     remote C=6 event via an encrypted relay event; fetchAndMerge() decrypts
     and merges it — no direct overrideRegisters writes, no hand-set isLoadComplete.
   - drain_crashAfterAppliedRead_newerRemoteUnread_noRebump: mirror, delivers
     remote S=7 via relay event through production path.

2. New manager-level witnesses:
   - drain_deferredRefusalAfterRestart_intentHydratedAndRefused (Test 43):
     intent persisted to v2 blob, hydrated on restart, refused on drain
     — confirms deferred-refusal surfaces outcome.
   - markChannelUnread_storageFailed_intentInMemoryOnly (Test 44):
     storage failure on enqueue: intent stays in-memory, no v2 blob write
     — confirms graceful degradation under storage_failed.

3. Hook-level (useUnreadChannels) pre-ready witnesses:
   - preReady_markChannelUnread_appearsInUnreadChannelIds_beforeLoadComplete:
     pending unread is visible via computePreReadyUnread before load completes.
   - preReady_markChannelRead_suppressesForcedEntry_sourcePreserved_refusalRestoresMultiSource:
     queued read suppresses committed forced entry without deleting sources.

4. noopMarkChannelUnread/noopMarkChannelRead in useReadState.ts enqueue
   intents when no manager is available, so pre-ready presentation works even
   before the relay client is initialized.

5. useUnreadChannels.ts: condense else branch to single line (ratchet fix,
   1019 wc -l = 1020 split, within the 1021 limit).

Co-authored-by: Will Pfleger <pfleger.will@gmail.com>
Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
 2026-08-07 19:40:59 -04:00
Taylor Ho
02f640bc45 feat(desktop): unify add agent flows (#5015) 
**Category:** improvement
**User Impact:** Users can create, discover, and import agents from one
consistent Add agent dialog.

**Problem:** Agent creation, discovery, and import were split across a
dropdown and separate dialogs, making the Add agent flow fragmented. The
existing E2E suite also continued targeting the deleted dropdown after
the flows were unified.

**Solution:** Route the new-agent card directly into a unified dialog
with dedicated Create, catalog, and Import navigation, then update the
affected E2E coverage to exercise that interface and its current empty
state.

<details>
<summary>File changes</summary>

**desktop/src/features/agents/ui/AgentDefinitionDialog.tsx**
Supports rendering the agent definition form inside the unified Add
agent experience while retaining the standalone dialog behavior.

**desktop/src/features/agents/ui/AgentDefinitionDialogShell.tsx**
Adds the shared shell used to present agent-definition content
consistently in embedded and standalone contexts.

**desktop/src/features/agents/ui/AgentDialog.tsx**
Passes the revised dialog state and close behavior through the existing
agent dialog entry point.

**desktop/src/features/agents/ui/AgentsView.tsx**
Connects the Agents page to the unified Add agent dialog and opens newly
added catalog agents in their profile panel.

**desktop/src/features/agents/ui/PersonaCatalogDialog.tsx**
Combines catalog browsing, agent creation, and snapshot import behind
persistent navigation, including dirty-navigation confirmation.

**desktop/src/features/agents/ui/UnifiedAgentsSection.tsx**
Replaces the new-agent dropdown with a direct Add agent entry point and
adjusts the responsive card grid.

**desktop/src/features/agents/ui/personaLibraryCopy.ts**
Updates catalog-facing copy for the unified experience.

**desktop/src/features/agents/ui/usePersonaActions.ts**
Returns the resolved local persona after catalog activation so the
caller can open the added agent.

**desktop/tests/e2e/agent-readiness-screenshots.spec.ts**
Opens the embedded create pane directly for readiness screenshots.

**desktop/tests/e2e/agents.spec.ts**
Covers unified Create, catalog, and Import navigation and asserts the
current shared-agent empty state.

**desktop/tests/e2e/global-agent-config-screenshots.spec.ts**
Updates global configuration screenshot setup for direct create-pane
entry.

**desktop/tests/e2e/inline-custom-harness.spec.ts**
Updates custom harness setup for the embedded create form.

**desktop/tests/e2e/persona-env-vars.spec.ts**
Updates environment-variable and model-provider scenarios for direct
create-pane entry.

**desktop/tests/e2e/persona-model-combobox-screenshots.spec.ts**
Updates model combobox screenshot setup for direct create-pane entry.

**desktop/tests/e2e/smoke.spec.ts**
Updates agent-creation smoke coverage for the unified Add agent dialog.

**desktop/tests/e2e/where-to-run-config.spec.ts**
Updates provider-selection coverage for the embedded create form.

</details>

## Reproduction steps

1. Open the Agents page and select the new-agent card.
2. Confirm the Add agent dialog opens directly on Create without an
intermediate dropdown.
3. Use the left navigation to browse shared agents and open Import.
4. Select a catalog agent and confirm the dialog closes and the added
agent's profile panel opens.
5. Run the affected desktop Playwright smoke and integration specs and
confirm all scenarios pass.

---------

Signed-off-by: Taylor Ho <taylorkmho@gmail.com>
Co-authored-by: Carl <acda9e433d19dcd0e6b6840f7f4b98f3a56f1fab98049d444c087019e6d36560@buzz.block.builderlab.xyz>
 2026-08-07 16:25:49 -07:00
Tyler
c7b663680a fix(buzz-agent): budget summarizer reasoning separately so it cannot starve the handoff summary (#5248) 
## Problem

The handoff summarizer sends `max_tokens: 8192`
(`HANDOFF_MAX_OUTPUT_TOKENS`) with no reasoning budget separation. On
reasoning models, thinking tokens count against that cap: the model can
spend the entire budget reasoning, length-stop with empty `content`, and
`summarize()` — which only reads `content` — reports an empty summary.
The handoff then degrades to lossy history truncation.

Observed on deepseek-v4-flash during a terminal-bench 2.1 run
(tb21-solo-3, 89 tasks): **13 consecutive handoff attempts across 5
trials failed exactly this way** (`handoff returned empty summary;
truncating`), each burning ~3 minutes of full-cap reasoning, before a
stochastically-short reasoning run finally fit. circuit-fibsqrt alone: 5
failures, 5 truncations, then success on attempt 6. video-processing
failed its task by one frame after 3 context truncations.

## Fix

`openrouter_summary_body` now grants reasoning its own equal-sized
budget and excludes it from the response:

- `reasoning.max_tokens = max_output_tokens` — thinking gets a dedicated
budget instead of competing with the summary text
- `reasoning.exclude = true` — reasoning is never in the response body;
`summarize()` only reads `content`
- `max_tokens = max_output_tokens * 2` — the total cap covers both
budgets, so the text budget the caller asked for is actually available
for text

Non-reasoning endpoints ignore the `reasoning` object. Deliberately not
paired with `provider.require_parameters`, for the reasons documented at
`apply_openrouter_mutations` (it hard-404s valid model ids).

The prior test
`openrouter_summary_carries_neither_reasoning_nor_provider` asserted
`reasoning` absent from the summary body — that assertion guarded
against *effort-based* reasoning leaking in from config (the body is
built independently of `cfg`, which is still true and still tested:
`reasoning.effort` stays unset). Replaced with
`openrouter_summary_budgets_reasoning_separately_and_carries_no_provider`.

## Verification

- `cargo test -p buzz-agent`: 422 unit + 110 integration tests pass at
bb2fedde
- `cargo fmt` / `cargo clippy -p buzz-agent --all-targets`: clean
- Not yet validated against a live OpenRouter reasoning endpoint — the
failing scenario needs a long-context session to trigger organically.
Evidence for the mechanism is from run artifacts (13/13 empty-summary
length-stops on deepseek-v4-flash) and OpenRouter's documented
`reasoning.max_tokens`/`reasoning.exclude` semantics.

---------

Signed-off-by: Eva <011987e296fd5006292d2f930b574be47c7801048d1983c46c425d3c95f0cffd@buzz.block.builderlab.xyz>
Co-authored-by: Eva <011987e296fd5006292d2f930b574be47c7801048d1983c46c425d3c95f0cffd@buzz.block.builderlab.xyz>
 2026-08-07 19:18:05 -04:00
Paweł Karniej
65834d68d0 infra: bind development services to loopback (#4871) 
## What changed

Bind the development Compose stack's published PostgreSQL, Redis,
Adminer, Keycloak, MinIO, and Prometheus ports to `127.0.0.1`.

## Why

Docker publishes a host port on every interface when no host address is
specified. Running the development stack on a remote workstation or VPS
therefore exposes its infrastructure services to that machine's public
networks. Loopback bindings retain host-local development access and
Docker's internal `buzz-net` connectivity without making those services
Internet-reachable.

## Impact

Local workflows continue using the same ports. Deliberate remote
administration now requires an SSH tunnel or another trusted
private-network path.

## Validation

- `docker compose -f docker-compose.yml config --quiet`
- Recreated the six affected services with their existing named volumes
and Docker network
- PostgreSQL remained healthy and retained all 54 application tables
- Redis, MinIO, and Prometheus health checks passed
- All affected ports were closed on the host's public IPv4 and IPv6
addresses while remaining available on loopback

Origin:
`buzz://message?channel=199eb7bc-3feb-484f-ae0e-4995123721ea&id=1c5bc387e86e21bb31677f56e1c862d4d9a17943bce91f8d93e825d029ce7f72`

Signed-off-by: Paweł Karniej <karniej.p@gmail.com>
 2026-08-07 16:09:44 -07:00
Duncan
24e87e85c7 fix(readState): v4 plan conformance — pending-intents consolidation, single-flight retry controller, biting witnesses 
Closes all 7 IMPORTANT + 2 MINOR findings from Thufir pass-1.

Core changes:
- Consolidate pending-intents storage into override-state.v2 blob (Paul's
  design ruling). Single write point for registers, receipts, and intents
  eliminates the double-commit window; no migration needed since
  pending-intents.v1 never shipped.
- Implement retryLoad() single-flight controller: bounded exponential backoff
  (1s->2s->4s...60s cap), reconnect coalescing into pendingRetryOnComplete,
  destroy/identity cancellation, retryAttempt reset on complete verdict.
- sourceScope + readTarget captured in enqueue path so drain performs exact
  source cleanup at the correct frontier position.
- refused-unread rollback: snapshot prior forced-unread entry before ordered
  write; restore exact snapshot on refusal; delete only when no prior existed.
- Surfaced drain outcomes via onDrainOutcome hook; genuine refusals
  (uint32_overflow, budget_exhausted, storage_failed) trigger toast;
  already_inactive is silent success; load_incomplete never surfaces.
- Cleanup atomicity: intent + receipt deleted in a single persistLocalState()
  call (one v2 blob write) so they are never observable separately.
- createDrainContext typed factory replaces this-as-unknown-as-DrainContext cast.
- NIP-RS.md: added normative refusal-reason vocabulary list.

Biting witnesses added (readStateManager.test.mjs, +12 tests):
- Amendment A: gen2 enqueued mid-replay, gen1 register rolled back
- Both inversion directions (unread->read, read->unread in-flight)
- compare-delete preserves newer intent
- Amendment C via production fetchAndMerge load path (not direct register write)
- Atomic intent+receipt deletion witness
- Controller: automatic backoff, reconnect during loadInFlight, stale-gen ordering
- Controller: destroy-with-timer, exactly-one-drain-per-generation
- Store/UI: identity-swap-during-drain, deferred refusal surfaces outcome

Co-authored-by: Will Pfleger <pfleger.will@gmail.com>
Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
 2026-08-07 18:53:39 -04:00
Wes
13c9e900c8 chore(release): release Buzz Desktop version 0.5.7 (#5252) 
## Buzz Desktop release v0.5.7

- **Frozen main:** `74b913cff8512c015dc6f1a7473b253fa803f954`
- **Reviewed candidate:** `f167818d25dd9f03115ab907a16f07daee2ece5c`
- **Previous desktop release:** `desktop-v0.5.6`
- **Proposed immutable tag:** `desktop-v0.5.7`

This PR may be **squash merged** after the Desktop Release Candidate
check and all protected-branch checks pass. Merging authorizes
publication of the exact reviewed candidate; later or unrelated changes
on `main` cannot alter it.

The checked-in changelog accounts for every non-merge commit in the
release range. The Desktop tag points to the reviewed candidate commit,
not the later squash commit. Publication remains bound to that immutable
candidate tag.

Signed-off-by: Wes <wesbillman@users.noreply.github.com>
Co-authored-by: Release Automation <release-automation@users.noreply.github.com>
 2026-08-07 15:37:12 -07:00
Wes
74b913cff8 fix(desktop): isolate relay admission tests (#5221) 
## Summary

- serialize the relay error-message test with all other tests mutating
the process-wide admission gate
- clear its 300-second rate-limit expiry after the assertion
- prevent the paused-time waiter test from observing another test's
state

## Root cause

`relay::tests::oversized_hint_is_capped_in_relay_error_message_string`
arms the process-wide gate for 300 seconds without taking `TEST_SERIAL`
or resetting it. In a parallel test run,
`relay_admission::tests::concurrent_429_extends_the_window_for_parked_waiters`
can observe that expiry, producing the reported `300.001s` instead of
`5s`.

## Validation

- focused admission suite + relay error test repeated 10 times
- pre-push `desktop-tauri-checks` passed, including the full Rust
workspace suite
- `branch-skew` passed

Signed-off-by: Wes <wesbillman@users.noreply.github.com>
Co-authored-by: Carl <c7ebe626f000404285d3686e1dc74cc07cc60a9754a150041ba132e14bd3e2ec@buzz.block.builderlab.xyz>
 2026-08-07 15:09:07 -07:00
Will Pfleger
dcc1231d6d fix(desktop): externalize boot <style> to prevent Tauri CSP nonce override (#5242) 
## Problem

Two v0.5.6-only regressions were introduced by #4614 (the first enforced
Tauri CSP):

1. **Tab-complete caret regression** — after tab-completing an @mention,
#channel, or :emoji: shortcode, the cursor landed inside the inserted
text instead of after the trailing space. TipTap inserts the correct
text including the trailing space, but without its base stylesheet
(`.ProseMirror { white-space: break-spaces }`) the trailing space
collapses visually and the caret appears mid-name.

2. **Emoji picker unstyled** — the emoji-mart picker rendered as a giant
unstyled layout (oversized search SVG, collapsed grid) because
emoji-mart's shadow-root stylesheet injection was also blocked.

Both symptoms have the same root cause.

## Root Cause

Tauri's build-time asset processor scans `index.html` for inline
`<style>` elements, injects a nonce token, and adds the corresponding
`'nonce-…'` source to `style-src` at runtime. Per the CSP spec, **once a
nonce is present in a directive, the browser ignores `'unsafe-inline'`
for that directive**.

`index.html` contained an inline `<style>` with the boot background
color. When Tauri nonced it and injected `'nonce-…'` into `style-src`,
the intended `style-src 'self' 'unsafe-inline'` became effectively
`style-src 'self' 'nonce-…'` — blocking any runtime stylesheet injection
not covered by a matching nonce:

- TipTap's `injectCSS()` → `createStyleTag()` injecting `.ProseMirror {
white-space: break-spaces; … }`
- emoji-mart's shadow-root `document.createElement('style')` injection

(Inline scripts follow a separate path — they are SHA-256 hashed, not
nonced.)

This only reproduces in packaged builds (where Tauri's custom protocol
serves the HTML and enforces the policy). `tauri dev` loads from the
Vite dev server and is not affected.

## Fix

Move `html { background-color: #000; }` from an inline `<style>` in
`index.html` to `desktop/public/boot.css`, linked via `<link
rel="stylesheet">`. A linked stylesheet is not subject to Tauri's nonce
injection, so `'unsafe-inline'` in `style-src` applies as declared.

The `<link>` is render-blocking (same as the inline style was), so
boot-flash behaviour is identical.

**The production CSP string is unchanged.** This fix makes the policy
apply as intended — no security properties are altered. Will's follow-up
with the security team (Jordan Mecom / Eli Foster, authors of #4614) is
noted for post-ship.

A Tauri-faithful CSP harness for the Vite dev path (so this class of
regression is visible before a packaged build) is tracked as a separate
follow-up.

## Files Changed

- `desktop/index.html` — replace inline `<style>` with `<link
rel="stylesheet" href="/boot.css" />`
- `desktop/public/boot.css` — new file, the extracted `html {
background-color: #000; }` plus rationale comment
- `desktop/src-tauri/tests/csp.rs` — update comment: nonce for styles,
SHA-256 for the boot script

## Testing

- `just desktop-typecheck` ✅
- `just desktop-test` ✅ (4535/4535)
- `just desktop-tauri-test` ✅ (all Rust tests including `csp.rs`)
- Packaged validation: `pnpm tauri build --debug` completed; compiled
binary bakes `style-src 'self' 'unsafe-inline'` with no nonce source
injected ✅

---------

Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
Co-authored-by: Duncan <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz>
 2026-08-07 15:05:38 -07:00
Taylor Ho
a5a9240241 fix(desktop): let imported and recovered identities finish onboarding (#5228) 
**Category:** fix
**User Impact:** People who onboard by importing an existing key or
recovering from a phone can now use "Skip for now" (and Next) on the
harness setup and model config steps, instead of getting stuck.

**Problem:** On the "Set up your agent harnesses" and "Configure your
default model settings" onboarding steps, clicking **Skip for now** — or
**Next** — did nothing for anyone who reached those steps by importing
an existing key or recovering an identity from a phone. The app stayed
frozen on the step.

**Solution:** The onboarding state machine sets `continuingPubkeyRef` to
the current pubkey on import/recovery to keep the flow on `onboarding`
until setup finishes (added in #4845). But `complete()` never cleared
that ref, so once it matched the current pubkey the stage stayed pinned
to `onboarding` forever — completion could never win. `complete()` now
clears the ref so finishing/skipping actually settles the flow.
Fresh-generated keys never set the ref, which is why first-run fresh-key
skip already worked and the gap went unnoticed.

<details>
<summary>File changes</summary>

**desktop/src/features/onboarding/machineOnboarding.ts**
Clear `continuingPubkeyRef` inside `complete()` so an imported/recovered
identity's "continuing" marker no longer outlives completion and pin the
stage to `onboarding`.

**desktop/tests/e2e/onboarding.spec.ts**
Add a regression test that imports an existing key, reaches harness
setup, clicks **Skip for now**, and asserts onboarding exits (reaches
community onboarding). This fails without the fix. The existing skip
tests only exercised the fresh-key path, which never set the ref — hence
the gap.

</details>

## Reproduction steps

1. Start onboarding and choose **Use an existing key** (or recover from
a phone); import a key and continue to **Set up your agent harnesses**.
2. Click **Skip for now** (or **Next**). Before this change, nothing
happens — the step is stuck. The same trap hits **Configure your default
model settings**.
3. With this change, Skip/Next advances out of onboarding as intended.
4. Automated: `pnpm build:e2e && pnpm exec playwright test
onboarding.spec.ts --project=integration -g "imported-key users can skip
out of harness setup"` — passes with the fix, fails without it.

## Root cause

Introduced by #4845 (`feat(identity): recover desktop identity from a
signed-in phone`), which added `continuingPubkeyRef.current ===
currentPubkey` as an independent condition selecting the `onboarding`
stage. That guard has no off switch: `complete()` set the completion
flag but never cleared the ref, so the OR'd condition kept the stage
pinned. Not a revert candidate — the guard's intent (keep a
just-published identity in onboarding until setup finishes) is correct;
it just needed to release on completion.

Signed-off-by: Taylor Ho <taylorkmho@gmail.com>
 2026-08-07 15:03:43 -07:00
Duncan
ba097710b0 fix(readState): route pre-ready reads through tri-state API, open rawUnread gate 
Fixes three Thufir pass-1 conformance defects in the incomplete-load path:

1. applyOverrideRead() no longer returns early before calling markChannelRead()
   when load is incomplete. The manager's queued branch is now reachable from
   the UI pre-ready. load_incomplete refusal (no relay client) still fails
   closed as overrideStillActive. Pre-ready null liveness is no longer treated
   as known absence; the null short-circuit is guarded behind isReadStateReady.

2. Both markContextRead() call sites (single-channel and markAllChannelsRead)
   are gated on overrideApis.isReadStateReady — no frontier mutation fires
   while the load is incomplete. Drain performs the authoritative advance on
   the next complete-load transition.

3. rawUnread opens the pre-ready gate for local forced entries and pending
   intents via computePreReadyUnread() (extracted to readStateOverride.ts).
   Precedence: pending read suppresses > pending unread asserts > committed
   forced entry. Partial manager/observed state is never consulted pre-ready.

Replaces two obsolete fail-closed tests with v4-conformant witnesses.
Adds four required biting witnesses (a)-(b)-(c)-(d):
  preReady_read_witness_a_queued_intent_recorded
  preReady_read_witness_b_zeroMutationZeroPublish
  preReady_unread_witness_c_pendingUnread_visible_during_loading
  preReady_read_witness_d_queued_read_preserves_sources_overrideStillActive

Co-authored-by: Will Pfleger <pfleger.will@gmail.com>
Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
 2026-08-07 17:41:11 -04:00
Duncan
dec35a502f chore(readState): remove dead clearChannelUnreadSource from useForcedUnreadActions 
useForcedUnreadActions.clearChannelUnreadSource was the pre-#3966 local-
only source-removal path.  It was superseded by useClearChannelUnreadSource
in readStateOverride.ts, which routes last-source removals through
applyOverrideRead so the NIP-RS register receives its C-bump cross-device.

useUnreadChannels.ts already destructures only markChannelUnread from
useForcedUnreadActions; the clearChannelUnreadSource return value has been
dead since the branch introduced useClearChannelUnreadSource.  Remove the
dead callback and the return slot (plan standing MINOR).

Co-authored-by: Will Pfleger <pfleger.will@gmail.com>
Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
 2026-08-07 16:50:01 -04:00
Duncan
d61d8b1178 refactor(readState): extract drain helpers into readStateDrain.ts 
Split the 427-line-over-ratchet readStateManager.ts by moving the
drain-path logic (drainPendingIntents, markChannelUnreadDirect,
markChannelReadDirect, markChannelUnread, markChannelRead) into a new
readStateDrain.ts module. The manager methods become thin delegations
that cast `this` to the DrainContext interface.

readStateDrain.ts exports a DrainContext interface (the public subset of
ReadStateManager state and methods needed for drain operations) and five
standalone functions that implement the Amendment A/B/C drain semantics
verbatim — no behavior change.

File-size ratchet (merge-base 2ea938501):
  readStateManager.ts: 959 → 1000 (allowed 1000) ✓
  readStateDrain.ts: 0 → 313 (new file, ≤1000) ✓
  useUnreadChannels.ts: 1021 → 1021 (allowed 1021) ✓

Tests: 4566/4566 ✓  tsc --noEmit clean ✓
Co-authored-by: Will Pfleger <pfleger.will@gmail.com>
Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
 2026-08-07 16:37:45 -04:00
Tyler
2b873cf208 Recover from max-token response truncation (#5223) 
## Summary

- treat provider `max_tokens` as an interrupted assistant response and
continue the same turn with actionable feedback
- discard tool calls from truncated responses, including malformed
partial arguments, so they are neither executed nor replayed with
invalid tool-result pairing
- bound recovery to two retries while preserving normal finite
`max_rounds` accounting

## Verification

- `cargo fmt --all -- --check`
- `cargo test -p buzz-agent` (422 unit tests plus all package
integration/doc suites passed)
- `cargo clippy -p buzz-agent --all-targets -- -D warnings`

## Notes

The pre-push repository-wide hook also ran. Its Rust tests passed (2,270
passed, 14 ignored), but its `buzz-db` unit-test build was blocked
because local rustc 1.89 is below sqlx 0.9's rustc 1.94 requirement. The
affected package suite above is green on the exact pushed commit.

Originating Buzz channel: `c3252dd2-0142-4e01-88c7-a2183c3960a5`

Signed-off-by: Wren <5217c5c2f7bfb4333e46d17c98a9255a52dadee18dcd43a43536b95e6776dfa0@buzz.block.builderlab.xyz>
Co-authored-by: Wren <5217c5c2f7bfb4333e46d17c98a9255a52dadee18dcd43a43536b95e6776dfa0@buzz.block.builderlab.xyz>
 2026-08-07 15:56:48 -04:00
Wes
3855687e76 chore(release): release Buzz Desktop version 0.5.6 (#5214) 
## Buzz Desktop release v0.5.6

- **Frozen main:** `78c87ae20e182fffdd99744d6c9ff99df82b159c`
- **Reviewed candidate:** `277d98a5cfb6d3b9af8b75122988f7a7df33ed5d`
- **Previous desktop release:** `desktop-v0.5.5`
- **Proposed immutable tag:** `desktop-v0.5.6`

This PR may be **squash merged** after the Desktop Release Candidate
check and all protected-branch checks pass. Merging authorizes
publication of the exact reviewed candidate; later or unrelated changes
on `main` cannot alter it.

The checked-in changelog accounts for every non-merge commit in the
release range. The Desktop tag points to the reviewed candidate commit,
not the later squash commit. Publication remains bound to that immutable
candidate tag.

Signed-off-by: Wes <wesbillman@users.noreply.github.com>
Co-authored-by: Release Automation <release-automation@users.noreply.github.com>
 2026-08-07 14:54:16 -04:00
Taylor Ho
07999425dc fix(mobile): keep latest messages above composer (#4981) 
**Category:** fix
**User Impact:** Mobile users who jump to Latest now see the newest
message fully above the composer instead of partially hidden behind it.

**Problem:** The channel message list treated the raw viewport bottom as
the latest boundary even though the composer occupies part of that
viewport. Latest jumps and follow-mode corrections could therefore place
the newest message underneath the composer.

**Solution:** Derive the latest alignment from the measured composer
inset and use that same boundary for scrolling, follow detection, and
layout correction.

<img width="498" height="1008" alt="Screen Recording 2026-08-05 at 5 18
19 PM"
src="https://github.com/user-attachments/assets/a7fc1a94-3ffb-4c34-908d-9bf4f3f082b4"
/>


<details>
<summary>File changes</summary>

**mobile/lib/features/channels/channel_detail_page/message_list.dart**
Aligns Latest navigation and follow-mode correction with the visible
bottom edge above the composer, and evaluates boundary state against the
same geometry.

**mobile/test/features/channels/channel_detail_page_test.dart**
Adds a regression assertion that the newest live message clears the
composer and that the Latest control disappears after navigation.

</details>

## Reproduction steps

1. Open a mobile channel with enough messages to scroll away from the
newest message.
2. Tap **Latest**.
3. Confirm the newest message is fully visible immediately above the
composer and the **Latest** control disappears.
4. Resize the composer or keyboard while following latest and confirm
the newest message remains above the composer.

## Tested fix

The newest message remains fully visible above the composer after
jumping to **Latest**.

![Tested fix: latest message remains above the
composer](https://d24qwcpro867f5.cloudfront.net/repos/buzz/prs/4981/latest-above-composer-tested.gif)

## Validation

- `flutter analyze` — no issues
- `flutter test` — 1,243 passed

---------

Signed-off-by: Taylor Ho <taylorkmho@gmail.com>
 2026-08-07 11:38:25 -07:00
Brad Groux
78c87ae20e fix(sdk): preserve self-mention p tags in message and forum event builders (#4975) 
## What users saw

`buzz messages send` silently removed an explicitly supplied
self-mention. The caller passed `--mention <sender-pubkey>` and received
`accepted:true`, but the signed event had no matching `p` tag and
`mention_pubkeys` was empty.

## Why it happened

`nostr` 0.44 strips `p` tags matching the signer's pubkey by default.
The codebase already opts out with `.allow_self_tagging()` for identity
archive and unarchive requests, but the message and forum builders that
accept mentions did not. The library therefore removed the tag during
signing after the CLI had validated the explicit mention.

## What changed

Added `.allow_self_tagging()` to all three event builders that accept
mention tags:

- `build_message` (kind 9)
- `build_forum_post` (kind 45001)
- `build_forum_comment` (kind 45003)

An explicit mention now survives signing even when it matches the
sender.

## How this was tested

Added one regression test per builder. Each test signs with the same key
included in the mention list and asserts that the resulting event
preserves the self-referential `p` tag.

Validation at `cd0f30bca`:

```text
./bin/cargo fmt --all -- --check
cargo test -p buzz-sdk --lib
cargo test -p buzz-cli --lib
cargo clippy -p buzz-sdk -p buzz-cli --all-targets -- -D warnings
```

All 257 `buzz-sdk` tests and all 321 `buzz-cli` tests passed, and
formatting and strict Clippy checks completed successfully.

## Scope and non-goals

- Does not change mention validation, deduplication, or channel-member
checks.
- Does not change `normalize_mention_pubkeys`, which is not used by the
messages-send path.
- Does not add a dropped-mentions output field because the explicit tags
are now preserved.

Closes #4906.

---------

Signed-off-by: Brad Groux <bradgroux@hotmail.com>
Signed-off-by: npub17q2gdupkvswvk5kprwc7plergm4gn295uw6fe4mjyjv53ahuhtnq02jd3f <f01486f036641ccb52c11bb1e0ff2346ea89a8b4e3b49cd772249948f6fcbae6@digitalmeld.communities.buzz.xyz>
Signed-off-by: Brad Groux <3053586+BradGroux@users.noreply.github.com>
Signed-off-by: Wes <wesbillman@users.noreply.github.com>
Co-authored-by: npub17q2gdupkvswvk5kprwc7plergm4gn295uw6fe4mjyjv53ahuhtnq02jd3f <f01486f036641ccb52c11bb1e0ff2346ea89a8b4e3b49cd772249948f6fcbae6@digitalmeld.communities.buzz.xyz>
Co-authored-by: Wes <wesbillman@users.noreply.github.com>
Co-authored-by: Carl <c7ebe626f000404285d3686e1dc74cc07cc60a9754a150041ba132e14bd3e2ec@buzz.block.builderlab.xyz>
 2026-08-07 11:14:25 -07:00
Tsung-Han Yu
c3c39cc263 bump @tauri-apps/cli to ~2.11.4 to fix linux app icon issue (#4858) 
## Summary
<!-- What does this change and why? -->

#3419 is a tauri bug (https://github.com/tauri-apps/tauri/issues/15110),
which is already fixed in
https://github.com/tauri-apps/tauri/pull/15596. All we need is bump the
@tauri-apps/cli version to include the bug fix.

```sh
pnpm update --filter ./desktop @tauri-apps/cli@2.11.4
```

This pr simply includes the changes after running the update command.

### Related issue
<!-- Fixes #1234, or N/A. Before opening: search existing issues/PRs for
duplicates — link the closest one, or say "none found". -->

fix #3419

close #3436. this pr supersedes it.


### Testing
<!-- How was this verified? UI change? Include before/after screenshots
(or a short recording). -->

build the appimage and check the symlink in the appimage using
`unsquashfs`.
```sh
$ unsquashfs -o 944632 -ll /tmp/buzz/desktop/src-tauri/target/release/bundle/appimage/Buzz_0.5.4_amd64.AppImage | grep -i dirIcon
lrwxrwxrwx root/root                 8 2026-08-04 21:54 squashfs-root/.DirIcon -> Buzz.png
```

Signed-off-by: Tsung-Han Yu <14802181+johan456789@users.noreply.github.com>
 2026-08-07 11:07:07 -07:00
Taylor Ho
1922d49cb2 feat(desktop): adding rich link previews to messages (#3818) 
## Overview

**Category:** improvement  
**User impact:** Link previews appear in the composer and travel as
privacy-safe sender-authored snapshots, so recipients never contact the
linked site merely by opening a conversation.
**Problem:** Cold-cache link paste could freeze the composer before the
URL painted; recipient-side unfurling leaked visits; invalid or
unresolved preview work could interfere with sending or leave dead cards
behind.
**Solution:** Paint pasted links before starting cold resolver work,
resolve only in the sender's composer, attach only complete validated
snapshots at Send, and render authored snapshots without recipient
fallback fetching.

## Behavior

- **Cold paste stays responsive:** bare and angle-bracket URL paste
paths commit the visible link before resolver work begins.
- **Sender-only fetching:** metadata is resolved while composing;
recipients render only the sender-authored snapshot.
- **Send never waits:** pending, failed, invalid, and unsendable
previews are omitted. They do not block or cancel the message.
- **Terminal misses disappear:** failed, timed-out, or 404 resolver
results remove the composer card while preserving visible link text.
- **Display-text links work:** Markdown links such as `[review the pull
request](…)` produce and send the same snapshots as bare URLs.
- **Compact and Rich presentation:** Compact remains the default; Rich
preserves source description line breaks and paragraphs.
- **Immediate draft-wide dismissal:** clicking × immediately hides all
previews for the draft, suppresses links pasted later, and emits only
`["link-preview", "none"]`. No confirmation detour. Suppression resets
after send or clearing the draft.
- **Zero recipient fallback:** missing, stale, malformed, off-relay,
unsupported, or suppressed snapshots remain ordinary visible links;
recipients never regenerate them.

## Implementation

- Resolve previews from deferred composer URL state so paste can paint
first.
- Upload finished preview media to the active community relay and
snapshot only valid, sendable media references.
- Atomically capture ready snapshots at submit time; never append a late
preview after send.
- Validate snapshot and suppression tags in desktop/native and relay
ingestion, rejecting duplicate or mixed forms.
- Render composer previews as stable 55px attachment cards at desktop
and narrow widths.
- Add deterministic E2E coverage for cold paste,
ready/pending/failed/invalid previews, display-text links, multiline
Rich descriptions, immediate dismissal, later-pasted links, and
suppression reset.

## Validation

Validated head: `9807ba8952f190e76153834abf8ab61dd40be5e2`

- Push hooks passed: `check-push-org`, branch skew, desktop check,
mobile tests, desktop tests, Rust tests, and desktop Tauri checks.
- Focused screenshot E2E at the validated head: 5/5 passed across
Compact/Rich composer and recipient states, 800px/420px geometry,
display-text links, multiline descriptions, and immediate dismissal.
- PR CI was triggered for this exact head and is currently running;
completed checks are green at the time of this update.
- Worktree is clean and both PR head and validated branch resolve to
`9807ba895…`.

## Screenshots

### Compact composer

| Loading | Ready |
|---|---|
| ![Compact composer
loading](https://d24qwcpro867f5.cloudfront.net/repos/buzz/prs/3818/compact-composer-loading.png)
| ![Compact composer
ready](https://d24qwcpro867f5.cloudfront.net/repos/buzz/prs/3818/compact-composer-ready.png)
|

### Rich composer

| Loading | Ready |
|---|---|
| ![Rich composer
loading](https://d24qwcpro867f5.cloudfront.net/repos/buzz/prs/3818/rich-composer-loading.png)
| ![Rich composer
ready](https://d24qwcpro867f5.cloudfront.net/repos/buzz/prs/3818/rich-composer-ready.png)
|

### Responsive composer

| 800px loading | 800px ready |
|---|---|
| ![800px composer
loading](https://d24qwcpro867f5.cloudfront.net/repos/buzz/prs/3818/composer-800-loading.png)
| ![800px composer
ready](https://d24qwcpro867f5.cloudfront.net/repos/buzz/prs/3818/composer-800-ready.png)
|

| 420px loading | 420px ready |
|---|---|
| ![420px composer
loading](https://d24qwcpro867f5.cloudfront.net/repos/buzz/prs/3818/composer-420-loading.png)
| ![420px composer
ready](https://d24qwcpro867f5.cloudfront.net/repos/buzz/prs/3818/composer-420-ready.png)
|

### Recipient presentation

| Compact | Rich |
|---|---|
| ![Recipient
compact](https://d24qwcpro867f5.cloudfront.net/repos/buzz/prs/3818/recipient-compact.png)
| ![Recipient
rich](https://d24qwcpro867f5.cloudfront.net/repos/buzz/prs/3818/recipient-rich.png)
|

### Display-text Markdown link

| Composer | Recipient |
|---|---|
| ![Display-text link in
composer](https://d24qwcpro867f5.cloudfront.net/repos/buzz/prs/3818/display-text-composer.png)
| ![Display-text link with recipient
preview](https://d24qwcpro867f5.cloudfront.net/repos/buzz/prs/3818/display-text-recipient.png)
|

### Rich multiline description

![Rich preview preserving description
paragraphs](https://d24qwcpro867f5.cloudfront.net/repos/buzz/prs/3818/rich-multiline-recipient.png)

### Immediate dismissal

| Before × | Immediately after × |
|---|---|
| ![Preview before immediate
dismissal](https://d24qwcpro867f5.cloudfront.net/repos/buzz/prs/3818/dismissal-before.png)
| ![Composer immediately after preview
dismissal](https://d24qwcpro867f5.cloudfront.net/repos/buzz/prs/3818/dismissal-after.png)
|

---------

Signed-off-by: Taylor Ho <taylorkmho@gmail.com>
 2026-08-07 10:56:08 -07:00
Will Pfleger
742e8d1197 fix(buzz-agent): Responses reasoning summary, Anthropic display:summarized, ACP v2 messageId (#5195) 
Three pre-existing gaps in the buzz-agent observer feed fixed together
per Will's ruling ("all 3 in the current PR"):

1. **OpenAI/DBv2-GPT route** — `responses_body` never requested
`reasoning.summary`; GPT-family models billed thinking tokens but
returned `summary: []`.
2. **Anthropic/DBv2-Claude route** — `anthropic_thinking_config()` never
sent `thinking.display`; newest Claude models (Opus 5, Sonnet 5, Fable
5, Mythos 5, Opus 4.7/4.8, Mythos Preview) default to
`display:"omitted"`, returning thinking blocks with an empty `thinking`
field — observer rendered nothing.
3. **ACP v2 compliance** — buzz-agent negotiates ACP v2 but emitted
`agent_thought_chunk` and `agent_message_chunk` without `messageId`,
which ACP v2's `ContentChunk` requires (`messageId` + `content` both
required at schema head `d13d1baa`).

## Changes

**`crates/buzz-agent/src/config.rs`**
- New `ThinkingSummary` enum (`Auto`/`Concise`/`Detailed`) with
`BUZZ_AGENT_THINKING_SUMMARY` env var (default `Auto`); mirrors
`BUZZ_AGENT_THINKING_EFFORT` pattern
- `anthropic_thinking_config()` now emits `"display": "summarized"` in
both the adaptive shape and the manual-budget shape whenever thinking is
enabled
- Rewrote `is_adaptive_thinking_model` and `anthropic_thinking_config`
doc comments to match Anthropic's exact three-way per-model terminology
(doc:
https://platform.claude.com/docs/en/build-with-claude/thinking-troubleshooting#supported-models):
- Opus 4.6/4.7/4.8, Sonnet 4.6: **Off** — thinking OFF by default;
`type:"adaptive"` required to enable
- Opus 5, Sonnet 5: **On** — thinking on by default, can be disabled; we
still send `type:"adaptive"` to activate `output_config.effort`
- Fable 5, Mythos 5, Mythos Preview: **Always on** — thinking cannot be
disabled; we still send `type:"adaptive"` to activate
`output_config.effort`

**`crates/buzz-agent/src/llm.rs`**
- `responses_body` emits `reasoning.summary` alongside
`reasoning.effort` when effort is set (gated — no bare
`reasoning:{summary}` without effort)
- Covers both the pure-OpenAI Responses path and the DBv2 GPT-family
Responses path

**`crates/buzz-agent/src/agent.rs`**
- `agent_thought_chunk` carries `"messageId":
format!("{run_id}-thought-{round}")`
- `agent_message_chunk` carries `"messageId":
format!("{run_id}-message-{round}")`
- The two IDs are distinct (thought and assistant are two logical
messages per the ACP v2 Message ID RFD)
- `run_id` is a fresh random token per `session/prompt` invocation so
IDs are session-unique across multiple prompts

**`crates/buzz-agent/src/lib.rs`**
- `run_id` plumbed into `RunCtx` (was already generated in `run_prompt`,
just not threaded through)

**`crates/buzz-agent/tests/golden_transcripts.rs`**
- `test_acp_v2_chunks_carry_message_id` — negotiates v2, drives two
consecutive `session/prompt` calls, asserts: both chunk types carry
non-empty `messageId`; thought and message IDs are **distinct**; IDs do
**not** recur across the two prompts in the same ACP session

**`desktop/src-tauri/src/managed_agents/env_vars.rs`**
- `BUZZ_AGENT_THINKING_SUMMARY` added to `is_safe_to_reveal` allowlist

**`desktop/src-tauri/src/commands/agent_config_tests.rs`**
- Tests for `BUZZ_AGENT_THINKING_SUMMARY` allowlist entry
(case-insensitive)

## Tests added

- `parse_thinking_summary_round_trips_all_values`
- `parse_thinking_summary_unset_and_empty_yield_auto`
- `parse_thinking_summary_is_case_insensitive`
- `parse_thinking_summary_rejects_unknown_value`
- `thinking_summary_as_str_mapping`
- `responses_body_summary_present_iff_effort_set`
- `responses_body_emits_configured_summary_mode`
- `responses_body_concise_summary_mode`
- `anthropic_thinking_config_adaptive_emits_display_summarized`
- `anthropic_thinking_config_manual_budget_emits_display_summarized`
- `test_acp_v2_chunks_carry_message_id` (integration test — two-prompt
cross-session case)

## Notes

- **DBv2 gateway parity for `display`**: unverified — the DBv2 Claude
route proxies Anthropic Messages shape, but whether the gateway passes
`thinking.display` through is not confirmed. Flagged here rather than
blocking on it.
- buzz-acp and Desktop TS are unchanged — they already parse `messageId`
as optional and will pick it up from the wire automatically.
- Chat Completions and OpenRouter paths: untouched.

---------

Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
Co-authored-by: Duncan <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz>
 2026-08-07 13:45:43 -04:00
Atish Patel
e9925db54e fix(desktop): retain distinct agent instances in autocomplete (#5202) 
## Summary
- preserve each distinct agent pubkey in autocomplete even when agents
share a persona or owner/name
- continue to collapse duplicate source rows for the same normalized
pubkey
- show a truncated pubkey in the channel member-add picker so same-named
instances are selectable

## Validation
- `pnpm --filter buzz test` — 4,489 passed
- `pnpm --filter buzz exec tsc --noEmit --pretty false`
- `pnpm --filter buzz exec biome check
src/features/agents/lib/agentAutocompleteEligibility.ts
src/features/agents/lib/agentAutocompleteEligibility.test.mjs
src/features/channels/ui/MembersSidebar.tsx`
- independent validation by Fast Fizz on
`509cb8d97b82f9708e24d4d59ad17c7b39516643`: typecheck, focused Biome,
22/22 focused tests, and `git diff --check`

Generated by Hardworking Honey.

---------

Signed-off-by: Hardworking Honey <c5c455215c2506cb8ba776518cec804af62d3a0526e32d496a22072e395042b9@buzz.block.builderlab.xyz>
Co-authored-by: Hardworking Honey <c5c455215c2506cb8ba776518cec804af62d3a0526e32d496a22072e395042b9@buzz.block.builderlab.xyz>
 2026-08-07 17:31:59 +00:00
Kevin Chung
ef2ecaf873 fix(desktop): defer channel visibility change to Save (#5203) 
## Problem

In the **Edit channel** dialog, flipping visibility (Public <> Private)
persisted **immediately on selection**, bypassing the **Save changes**
button — while every other field (name, description, temporary, TTL)
waited for an explicit save. This surprised users and gave no chance to
cancel a flip, e.g. a private->public change that instantly exposes
channel history.

Reported in the Buzz "Welcome" channel by Kevin Chung.

## Root cause

The visibility dropdown was wired to `handleConvertVisibility()`, which
called the update mutation on selection. This was intentional at the
time (there was even an e2e test named `02 — visibility updates
immediately` and an "Updating…" spinner), but it is inconsistent with
the rest of the dialog and is the surprising behavior reported.

## Change (defer to Save)

- Visibility becomes a **deferred draft** like the other fields:
selecting a value updates local `isPrivateDraft` and marks the draft
dirty. The change commits via `handleSaveChannelEdits` (which already
handled visibility) on **Save**, and is discarded on **Cancel**.
- The dialog title now reflects the **pending draft**
(`nextVisibility`), so the pending choice is visible before saving.
- The edit-dialog reset restores `isPrivateDraft` from server state.
- Removed the now-dead `handleConvertVisibility` handler,
`isConvertingVisibility` state, the `channelIdRef` race guard it needed,
and the unused `isPending`/"Updating…" spinner path in
`ChannelPermissionsSettings` (no caller passes `isPending` anymore).

## Tests

- Rewrote e2e `02` -> **`visibility defers to Save`**: select -> Save
enabled -> title reflects draft -> Save -> persists; toggling back to
the original value clears the draft and disables Save.
- Extended `09` (cancel discards drafts) to also cover a visibility
change.
- Repurposed `10`: the stale-update race it guarded is architecturally
gone, so it now asserts an **unsaved visibility draft does not leak
across a channel switch**.

## Validation

- `pnpm typecheck` — clean
- `biome check` (changed files) — clean
- `pnpm test` — **4497 passed / 0 failed**
- `playwright test --project=smoke channel-controls` — **10 passed**

Signed-off-by: Kevin Chung <chung@squareup.com>
Co-authored-by: Fizz <e3f95089179cc1bcc68d70c334b9bdf670d0470496db90bcdbb20386963432da@buzz.block.builderlab.xyz>
 2026-08-07 17:25:13 +00:00
thomaspblock
fb73561e64 feat(desktop): Projects follow-ups — access restrictions, fast loading, activity feed polish (#5073) 
## Summary

Follow-up batch on the Projects overview (continues merged #1677):

- **Repository access restrictions** — repositories the viewer can't
reach are surfaced with a reason instead of failing silently.
Channel-ACL denials (which arrive as the same 404 as a missing repo, for
anti-enumeration) are re-classified using the repository's channel
binding and the viewer's memberships (`useRepositoryAccess.ts`,
`projectRepoAvailability.ts`).
- **Projects loads in seconds instead of minutes** — enumeration no
longer crawls every kind:5 deletion event on the relay. It fetches
project/repo announcements first, then queries deletions scoped to those
coordinates via chunked `#a` filters (3 queries instead of hundreds on
staging).
- **Activity feed layout polish** — bare event-type glyph beside the
headline (no badge circle), timeline spine runs through the avatars
connecting consecutive cards, linkable actor/project names are bold in
theme foreground, rounded hover state, alignment fixes.
- **Create button pinned** — the "+" create menu is pinned to the pane's
top-right corner (equal 16px insets) and no longer scrolls away with the
page header.
- **List controls as a table header** — the scope selector (left) and
sort + layout toggle (right) render as the first row of the list
container on the Projects/Repositories/PRs/Issues tabs; in card view the
identical bar stands alone with the cards below
(`ProjectsListHeaderBar.tsx`).
- **Repository rows show the git location** — subtitle is
`github.com/org/repo` for external repos or `owner/repo` (resolved
profile name) for Buzz-hosted ones, instead of repeating the project
name (`repositoryDisplayPath`).
- **Uniform work-item row heights** — issue rows previously ran the
author chip in inline flow, letting the 20px avatar grow the line box
~3px taller than PR rows; both lists now share the same flex subtitle.

📸 Screenshots: [feed layout / pinned
button](https://github.com/block/buzz/pull/5073#issuecomment-5214114069)
· [list header / repo subtitles / row
heights](https://github.com/block/buzz/pull/5073#issuecomment-5217480712).

Note: two empty `chore: retrigger CI` commits exist on the branch from
working around the Aug 6 GitHub Actions incident; happy to drop them
with a signoff rebase before undrafting if preferred. Latest `main` is
merged in (`a0cc35220`).

## Test plan

- [x] Desktop unit tests (4,493 pass after merging main), Biome, tsc
- [x] New unit tests for scoped deletion enumeration and repo
availability re-classification
- [x] New unit tests for `repositoryDisplayPath` (external, Buzz-hosted,
unresolvable)
- [x] Screenshot verification of feed layout, connector spine, and
pinned button (top + scrolled states) — posted to the PR
- [x] Screenshot verification of the list header row (list + card), repo
subtitles, and matching PR/issue row heights — posted to the PR
- [ ] Manual pass against staging (projects list load time,
restricted-repo states)

---------

Signed-off-by: Thomas Petersen <thomasp@squareup.com>
 2026-08-07 19:23:35 +02:00
Will Pfleger
b2ac66cde8 refactor(cli): replace probe/decider/detail split with single typed extractor (#5191) 
Replaces the four-helper auth resolution path with two focused functions
and adds production async tests that count relay round-trips.

**Before:** `resolve_auth` called `resolve_auth_from_profile`
(warn-emitting probe into a throwaway sink) → `resolve_auth_deciding`
(re-classified the same profile) → `handle_auth_failure` →
`auth_failure_detail` (third classification). `Option<Option<&Value>>`
encoded a sentinel for unreachable state; tests exercised only the pure
sync helper, not the actual fetch count.

**After:**

- `extract_auth(profile, target, signer) -> Result<[String;4],
AuthFailure>` — pure typed extractor; `AuthFailure` now covers
`NoProfile` and `NoTagsArray` inline, no separate helper needed
- `resolve_auth()` is now the linear state machine: self-check → fetch +
extract → on failure: fetch again → route final `Err` to
`CliError::Usage` (default) or one admin warning (`--admin`). No
throwaway sinks, no duplicate classification, no sentinel type.
- Five async tests drive the production resolver through a counted Axum
test server on `POST /query` and assert on both return value and exact
fetch count: first success (1), retry success (2), double failure / no
`--admin` (2 + `Err`), double failure / `--admin` (2 + `Ok(None)` + one
warning), self path (0). Two parser tests pin `--admin` on both
`archive` and `unarchive`.
- `--admin` short help text corrected to describe when the flag takes
effect (after extraction fails, not unconditionally).

341 tests passing, clippy clean, fmt clean.

---------

Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
Co-authored-by: Duncan <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz>
 2026-08-07 13:12:08 -04:00
iroiro147
e47894a133 fix(desktop): drop unhandled rejection from throwing window.Notification (#5143) 
## Summary

WebKit throws `NotificationError` from the `Notification` constructor
when the notification backend becomes temporarily unavailable (measured
repro attached to #5081). Every existing call site used `void
sendDesktopNotification(...).then(...)` — discarding the returned
promise with no rejection handler — so a throwing constructor became an
unhandled promise rejection. The notification was silently dropped and
the only trace was console noise.

Closes #5081.

## What changed

Fenced the throw at the source inside `sendDesktopNotification`
(`desktop/src/features/notifications/lib/desktop.ts`):

- A new `try { ... } catch { ... }` wraps `new window.Notification(...)`
and the `onclick` attach.
- On catch, we `console.warn` once and `return false`, so the promise
the call sites discard is always fulfilled with the same boolean result.
No caller needs to change.

## Why at the source and not at each call site

The issue body lists four rejecting edges:
`useAppShellDesktopNotifications` (2×), `useReminderNotifications`,
`use-feed-desktop-notifications`. Patching them one-by-one leaves the
door open for the next consumer to make the same mistake — and the
function itself advertises `Promise<boolean>`, so callers are entitled
to assume the promise resolves with the delivery bit rather than
rejects. Fixing the inside satisfies both properties for every present
and future caller.

## Test plan

- Behavior change is a guarded return value around a single constructor;
unit coverage is best expressed inside the mounted-hook harness already
used in the repro. Existing notification helpers
(`shouldNotify*.test.mjs`) continue to pass.
- Full `just ci` runs on the blocker.
- The next notification after a backend blip delivers normally (the
throw is per-call, not sticky).

## Note on scope

This addresses the titled bug: unhandled rejection from a throwing
constructor. A separate, intended follow-up is to wire a user-visible
delivery-miss event if the platform exposes one — that's
notification-observability work, not a } catch.

---------

Signed-off-by: iroiro147 <sarthak.singh@mastersunion.org>
Signed-off-by: Wes <wesbillman@users.noreply.github.com>
Co-authored-by: Wes <wesbillman@users.noreply.github.com>
Co-authored-by: Carl <c7ebe626f000404285d3686e1dc74cc07cc60a9754a150041ba132e14bd3e2ec@buzz.block.builderlab.xyz>
 2026-08-07 09:37:39 -07:00
iroiro147
8630e58eb0 fix(desktop): fence localStorage SecurityError from killing the React tree (#5142) 
## Summary

WebKit throws `SecurityError` from `localStorage.getItem` (not just
`setItem`) when storage access is denied for the origin. With no
`ErrorBoundary` in `desktop/src`, any such throw inside a provider
render (`ThemeProvider`, `CommunitiesProvider`, `App` boot) propagated
to the reconciler, unmounted the root, and left a blank window. Measured
repro in #5078: a single throwing `getItem` on `buzz-communities` or
`buzz-active-community-id` kills the container.

Closes #5078.

## What changed

**New helper — `desktop/src/shared/lib/safeStorage.ts`**
- `getStorageItem(key, fallback?)` — wraps
`window.localStorage.getItem`; on a thrown error (SecurityError under
denied-storage origin) it warns once per key and returns the fallback.
- `setStorageItem(key, value)` and `removeStorageItem(key)` — same
fail-closed contract (return `false` on throw).
- Unit tests in `safeStorage.test.mjs` cover the happy path and the
`SecurityError` path.

**Rewired the init-path readers that ran before any UI existed**
- `desktop/src/features/communities/communityStorage.ts` —
`migrateLegacyCommunityStorage`, `loadCommunities`,
`loadActiveCommunityId`, `loadCommunityDiscoveryAfterLeave`,
`initFirstCommunity`
- `desktop/src/features/communities/legacyCommunityStorage.ts` —
`migrateLegacyCommunityStorageBeforeRender`
- `desktop/src/shared/theme/ThemeProvider.tsx` — `readStoredTheme`,
`applyCachedVars`, the `useState` initialisers for `accentColor` and
`followSystem`, and the accent re-read inside `applyTheme`

**Root-level fence — `desktop/src/app/RootErrorBoundary.tsx`**
- New top-level `ErrorBoundary` wrapping the whole provider tree in
`main.tsx`. Any remaining uncaught render error (a future storage read
that bypasses the helper, or any other render-time crash) renders a
degraded splash with a Reload button instead of a blank window.

## Test plan

- `desktop/src/shared/lib/safeStorage.test.mjs` — node `--test` runner,
11 assertions across healthy, absent, and SecurityError-throwing
storage.
- Full `just ci` runs on the blocker.
- Existing `communityStorage.test.mjs` and
`legacyCommunityStorage.test.mjs` continue to pass (they exercise the
same functions via in-memory Storage doubles; the new code path in
`migrateLegacyCommunityStorage` only adds a `try/catch` around the same
body).

## Why not an ErrorBoundary-only fix

A boundary alone can't help on a *clean* mount — the first throw already
unmounted the whole subtree before any state or fallback data was
loaded, so retrying would hit the same throw on the very next render.
The storage accessor has to fail closed *and* the boundary has to exist
for whatever bypasses it. Both are needed; neither is sufficient alone.

---------

Signed-off-by: iroiro147 <sarthak.singh@mastersunion.org>
Signed-off-by: Wes <wesbillman@users.noreply.github.com>
Co-authored-by: Wes <wesbillman@users.noreply.github.com>
Co-authored-by: Carl <c7ebe626f000404285d3686e1dc74cc07cc60a9754a150041ba132e14bd3e2ec@buzz.block.builderlab.xyz>
 2026-08-07 09:37:04 -07:00
Wes
cc9a2f7833 fix(desktop): make terminal output selectable (#4980) 
## Summary

- mirror the retained canvas terminal grid into a transparent,
selectable text layer
- preserve the canvas renderer and terminal focus behavior for ordinary
clicks
- reconstruct wide and combining glyphs correctly for clipboard text

## Why

Buzz Term renders output entirely on a canvas and deliberately called
`preventDefault()` on viewport mouse-down, so native selection and copy
could not work. A canvas has no selectable text even if that
cancellation is removed.

The transparent text layer stays aligned with the visible cell grid,
lets WebView native selection drive drag highlighting and copy, and
follows active-session switches without changing the renderer or PTY
protocol.

## Validation

- `pnpm --dir desktop typecheck`
- `pnpm --dir desktop test` — 4,373 passed
- pre-push `desktop-check`, `desktop-test`, and `branch-skew` hooks
passed on `1f2a3f8db63f6fe36b4a28bc911aea3c5186b2b0`

---------

Signed-off-by: Wes <wesbillman@users.noreply.github.com>
Co-authored-by: Carl <c7ebe626f000404285d3686e1dc74cc07cc60a9754a150041ba132e14bd3e2ec@buzz.block.builderlab.xyz>
 2026-08-07 09:30:35 -07:00
Taksh Kothari
60ae74b656 fix(desktop): use WEBKIT_DMABUF_RENDERER_FORCE_SHM for NVIDIA/AppImage (#3654) (#4505) 
## Summary
- Heuristic and `--safe-rendering` now set
`WEBKIT_DMABUF_RENDERER_FORCE_SHM=1` instead of
`WEBKIT_DISABLE_DMABUF_RENDERER=1`
- Legacy `DISABLE_DMABUF` stays owned so operators can still set
`=0`/`=1` and take over the decision
- Linux troubleshooting docs updated to match (#3654)

## Test plan
- [ ] unit tests in `webkit_rendering::tests`
- [ ] On NVIDIA + WebKitGTK 2.52: workspace switch no longer SIGSEGVs
where the distro NVIDIA guard does not fire (Debian/Ubuntu
proprietary-NVIDIA may still crash — #3654 stays open for that path)
- [ ] `WEBKIT_DISABLE_DMABUF_RENDERER=0` still stands the heuristic down

---------

Signed-off-by: Taksh <takshkothari09@gmail.com>
Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
Co-authored-by: Alia <d32955ad69077062930cc46cfe2df30ca9aaf6f8e76422681265e9e9af704d78@buzz.block.builderlab.xyz>
Co-authored-by: Will Pfleger <pfleger.will@gmail.com>
 2026-08-07 12:24:27 -04:00
Wes
daa8877581 Make public starter channels best effort (#5192) 
## Summary
- treat public starter-channel provisioning as best-effort after
preserving the required private Welcome path
- let community onboarding complete and focus Welcome when the reported
metadata lookup error occurs
- remove the now-obsolete retry-toast expectations for optional starter
provisioning

## Scope
This intentionally does not change relay tombstone semantics or
auto-join existing public channels.

## Test plan
- `pnpm exec playwright test tests/e2e/deep-link-invite.spec.ts` (8
passed)
- `pnpm exec playwright test tests/e2e/onboarding.spec.ts --grep "failed
public starter channel setup"` (1 passed)
- `pnpm typecheck`
- `pnpm check`
- `pnpm test` (4483 passed)
- pre-push hook: branch-skew, desktop-check, desktop-typecheck,
desktop-test passed on `4658a07beb1e1d54443da5cd2e4a28fae0232f24`

---------

Signed-off-by: Wes <wesbillman@users.noreply.github.com>
Co-authored-by: Carl <c7ebe626f000404285d3686e1dc74cc07cc60a9754a150041ba132e14bd3e2ec@buzz.block.builderlab.xyz>
 2026-08-07 09:21:29 -07:00
klopez4212
8476ea05e7 Mobile: add anchored reaction popover (#5025) 
## Summary

- replace reaction-only mobile sheets with an anchored long-press
popover
- add haptics, a dimmed frosted spotlight, and a spring-staggered
reaction tray
- preserve the full action sheet whenever other message actions are
available
- keep existing reaction pills outside the spotlight and make long press
reliable across nested content

## Testing

- `flutter analyze`
- `flutter test` (1,248 tests)
- signed iPhone release build installed and launched

---------

Signed-off-by: kenny lopez <klopez4212@gmail.com>
 2026-08-07 17:17:06 +01:00
klopez4212
626e2c34a3 feat(mobile): add bee pull-to-refresh (#5059) 
## Summary

Replace Flutter's standard mobile pull-to-refresh indicator with our
animated Buzz bee.

## Testing

- `bin/just mobile-check`
- `bin/just mobile-test` (1,248 tests)
- Connected iPhone and Pixel 10

---------

Signed-off-by: kenny lopez <klopez4212@gmail.com>
Signed-off-by: Fizz <50a12680c76f1a52c0b7af8dbb17e02c583227c290fb93b9a3defb456114223f@buzz.block.builderlab.xyz>
Signed-off-by: Wes <wesbillman@users.noreply.github.com>
Co-authored-by: Fizz <50a12680c76f1a52c0b7af8dbb17e02c583227c290fb93b9a3defb456114223f@buzz.block.builderlab.xyz>
Co-authored-by: Wes <wesbillman@users.noreply.github.com>
Co-authored-by: Carl <c7ebe626f000404285d3686e1dc74cc07cc60a9754a150041ba132e14bd3e2ec@buzz.block.builderlab.xyz>
 2026-08-07 16:09:19 +00:00
klopez4212
c8743b2f20 Remove agent creation success modal (#5063) 
## Summary
- remove the post-creation private-key modal
- return directly to the underlying page with one “Agent created” toast
- preserve failed channel-attachment retry through an actionable toast

## Validation
- desktop checks and E2E build
- 4,392 desktop unit tests
- focused Playwright coverage for standard, customized, and
attachment-retry creation flows

Signed-off-by: kenny lopez <klopez4212@gmail.com>
 2026-08-07 17:03:16 +01:00
Will Pfleger
346ae8cadc fix(buzz-agent): escalate LLM timeouts per retry and log per-call latency (#5130) 
Non-streaming LLM calls (`"stream": false`) through slow model/provider
combinations routinely take longer than the fixed
`BUZZ_AGENT_LLM_TIMEOUT_SECS` window (default 240 s) to return their
first response byte. The retry loop then re-ran the identical 240 s bet
three times, failed the turn, and the ACP harness requeued the whole
turn from scratch: agents spent 30+ minutes producing nothing while
every attempt died at the same wall. And because the LLM path only
logged WARN lines on failure, a healthy-but-slow call was
indistinguishable from a wedged one.

### Timeout handling

- **Per-attempt escalation**: the per-request budget doubles after each
timeout failure (`base × 2^n`, capped at `max(1200 s, base)` —
`escalated_timeout()` in `llm.rs`), shared by the main `post()` loop and
`openrouter_post()`. Non-timeout retryables (429/5xx/connect) do not
escalate. A call that needs six minutes now succeeds on a later attempt
instead of never.
- **Per-request total timeouts**: enforcement moved from the
client-level `read_timeout` to `RequestBuilder::timeout()` on each LLM
request, so escalated budgets aren't silently floored by the shared
client and each attempt's bound covers connect through body completion.
Timeout error messages were updated to match the new semantics and still
point at `BUZZ_AGENT_LLM_TIMEOUT_SECS`.

### Observability

- One INFO line per completed LLM call: model, provider, `duration_ms`,
`input_tokens`, `cached_input_tokens`, `output_tokens`. Slowness and
prompt-cache effectiveness are now visible in harness logs without
waiting for a failure, and `None` vs `0` token reports stay
distinguishable. Handoff summarization calls log the same line with
duration only.
- The agent main loop wraps the call in a `session_id` tracing span so
each line is attributable to a session.

---------

Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
 2026-08-07 11:45:39 -04:00
Kalvin C
c293b3cd40 fix(agent): resolve oauth cache home cross-platform (#5151) 
## Summary

- resolve the OAuth cache home directory with the repository's
platform-aware `dirs` convention
- preserve the existing `.config/buzz-agent/oauth` cache layout on macOS
and Linux
- make the cache-path regression assertion portable across path
separators

## Problem

`buzz-agent` read only `$HOME` when constructing the OAuth token cache
path. Packaged Windows processes do not guarantee that Unix variable, so
OAuth source construction failed with `oauth cache: $HOME not set` even
though Windows had a valid user profile.

## Validation

Independent reviewers validated exact commit
`836d820483b141b7291170cb33535ac7cb49b2eb` on Windows/MSVC with `HOME`
unset and `USERPROFILE` present:

- `cargo +1.94.1 clippy -p buzz-agent --all-targets --locked -- -D
warnings`
- `cargo +1.94.1 fmt --all -- --check`
- `git diff --check f53bbd1..836d820`
- `auth::` tests: 11/11 passed with `HOME` unset
- full package lib target: 396 passed / 2 failed; identical-base
controls classified both as pre-existing Windows failures

The changed regression fails on the base with `$HOME not set` and passes
on this branch. `dirs 6.0.0` was already locked by other workspace
crates; the lockfile change adds only the `buzz-agent` dependency edge.

Signed-off-by: Kalvin C <kalvinnchau@users.noreply.github.com>
 2026-08-07 08:42:01 -07:00
klopez4212
cd2125c34b Improve video review readiness and controls (#5161) 
![inline-hover-timeline](https://raw.githubusercontent.com/block/buzz/d7e047a684a3908f8f01e59fde531b0fbae47b8a/pr-5161--inline-hover-timeline.png)


![thread-timecode-chip](https://raw.githubusercontent.com/block/buzz/d7e047a684a3908f8f01e59fde531b0fbae47b8a/pr-5161--thread-timecode-chip.png)


![review-modal-ready](https://raw.githubusercontent.com/block/buzz/d7e047a684a3908f8f01e59fde531b0fbae47b8a/pr-5161--review-modal-ready.png)

---------

Signed-off-by: kenny lopez <klopez4212@gmail.com>
 2026-08-07 07:45:18 -07:00
klopez4212
c71f658539 Polish advanced agent setup and Welcome composer (#4926) 
## Summary
- move **Run on** into Advanced, directly after **Who can send
instructions**
- reuse the modal’s shared dropdown styling
- give the Welcome guidance and composer matching glass treatment while
preserving the corrected exit layering

## Validation
- `pnpm -C desktop typecheck`
- focused Playwright: Run on configuration (3 passed)
- focused Playwright: Welcome onboarding flow (1 passed)
- desktop unit suite (4,290 passed)

---------

Signed-off-by: kenny lopez <klopez4212@gmail.com>
Signed-off-by: Kenny Lopez <klopez4212@gmail.com>
Signed-off-by: Watcher <bb7abfd757d0af7b66569d02ab9c0316b616f9d0c151ecf5b964344c462e7f8f@buzz.block.builderlab.xyz>
Co-authored-by: Watcher <bb7abfd757d0af7b66569d02ab9c0316b616f9d0c151ecf5b964344c462e7f8f@buzz.block.builderlab.xyz>
 2026-08-07 15:15:34 +01:00
Will Pfleger
ee9690a93c fix(cli): emit structured JSON warning when archive/unarchive owner-auth extraction fails (#4824) 
emit structured JSON diagnostics when NIP-OA owner-auth extraction fails
during `buzz agents archive`/`unarchive`

## Problem

When owner-auth extraction returned `None`, the CLI silently sent a bare
request. The relay replied with `400: missing auth tag` and the caller
had no way to know why extraction failed.

## Solution

Extract `resolve_auth_from_profile` — a sync function that owns all
three warning branches and the success path. `resolve_auth` reduces to:
self-check → fetch kind:0 → delegate.

- **Four distinct diagnostics**: no kind:0 profile / no tags array /
`classify_owner_auth_tag` failure (typed `AuthFailure` enum:
`NoAuthTag`, `AmbiguousAuthTag`, `WrongArity`, `NonStringElement`,
`InvalidOwnerHex`, `InvalidSigHex`, `OwnerMismatch`)
- **JSON format**: each fallback emits exactly one `{"warning":"..."}`
line to stderr, matching the CLI's documented structured-stderr contract
and the precedent in `channels.rs:597`
- **Relay-supplied values** (target pubkey, actual owner pubkey) pass
through `serde_json` serialization — no unescaped text
- **Admin bare path preserved**: request is always sent after the
warning; bare non-self requests are legitimate for relay admins
- **Self path unchanged**: silent, no relay query

## Boundary tests

Tests call `resolve_auth_from_profile` directly with `&mut Vec<u8>`.
Each of the three production `writeln!` calls is covered: deleting any
one fails at least one test. Success path asserts zero bytes written.

## Changes

`crates/buzz-cli/src/commands/agents.rs` only:
- `AuthFailure` enum with `message()` formatter
- `classify_owner_auth_tag` returning `Result<[String;4], AuthFailure>`
- `extract_owner_auth_tag` reduced to `#[cfg(test)]` `.ok()` wrapper
- `resolve_auth_from_profile` sync helper (testable without
`BuzzClient`)
- `resolve_auth` reduced to self-check + fetch + delegate
- 9 new boundary tests replacing the prior test-local helper

---------

Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
Co-authored-by: npub1mn7jgtj4w2pd0g0zeuhxsa6jy6p0rewxz4kujt98my82ahfmp72sxjexk7 <dcfd242e557282d7a1e2cf2e6877522682f1e5c6156dc92ca7d90eaedd3b0f95@buzz.block.builderlab.xyz>
 2026-08-07 10:14:43 -04:00
Tyler
f53bbd1152 fix(bench): mention the orchestrator by pubkey when posting the task (#5136) 
## Problem

The harness posts each trial's task via `buzz messages send`, relying on
`@<orchestrator-id>` name resolution. Task text is untrusted payload:
when it contains @-tokens of its own, the CLI's mention resolver tries
to resolve them as channel members, fails, and refuses to send — killing
the trial with `RuntimeLaunchError` before the agent ever saw the task.

Live occurrence: TB 2.1's `large-scale-text-editing` task embeds Vim
macros (`:%normal! @a`). In the tb21-solo-1 run the trial died at
launch:

```
RuntimeLaunchError: buzz messages send ... exited 1:
{"error":"user_error","message":"mention '@a' does not match a current channel member; retry with --mention <pubkey>"}
```

Any TB task whose statement contains @-syntax is silently zeroed this
way.

## Fix

Pass the orchestrator's pubkey as an explicit `--mention` when posting
the task. The CLI demotes unresolved @-tokens in the text to
presentation-only when any explicit identity is supplied, so delivery
still targets exactly the orchestrator and every @-token in the task
statement becomes inert. The harness already holds the orchestrator's
`AgentCredential` (it writes that pubkey into the worker roster tables),
so no persistence is needed — fresh key per trial, fresh `--mention` per
trial.

Verified both halves against a live relay: a fenced `@a` without
`--mention` still hard-fails (the resolver is not markdown-aware); the
same content with an explicit `--mention` sends clean with
`mention_pubkeys` containing only the target.

## Testing

- `benchmarks/harbor-buzz-orchestra`: full pytest suite — 35 passed (34
baseline + new `test_send_mentions_by_pubkey_so_task_text_stays_inert`),
ruff clean. Run against `origin/main` 769ac70b with exactly this patch
applied.
- `testbed`: full pytest suite — 23 passed, 1 skipped; ruff clean.

## Acceptance

A task statement containing arbitrary @-tokens (Vim registers, emails,
decorators) launches and delivers to the orchestrator instead of dying
in `_send`.

Originating Buzz thread:

`buzz://message?channel=c3252dd2-0142-4e01-88c7-a2183c3960a5&id=74a65a0990fd2197882b66b5ea2707169d4a3dbd2020d1610c45150fb99f140b`

Signed-off-by: Eva <011987e296fd5006292d2f930b574be47c7801048d1983c46c425d3c95f0cffd@buzz.block.builderlab.xyz>
Co-authored-by: Eva <011987e296fd5006292d2f930b574be47c7801048d1983c46c425d3c95f0cffd@buzz.block.builderlab.xyz>
mobile-v0.9.0-rc.1 		2026-08-06 22:27:29 -04:00
Tyler
ad923353a2 feat(relay): accept kind:30179 private managed-agent events at ingest (#5133) 
## What

Relay-only carve-out of the ingest half of #4999: generic EVENT ingest
now accepts kind:30179 (NIP-PMA private managed-agent config). One file,
`crates/buzz-relay/src/handlers/ingest.rs`, 16 insertions / 15
deletions; **two semantic lines**, byte-identical to the ingest hunk of
#4999 at `6f486e88`:

1. `required_scope_for_kind`: 30179 requires `Scope::UsersWrite` — same
arm as its public sibling 30177 and the other owner-authored NIP-AP
kinds.
2. `is_global_only_kind`: 30179 is owner-global, keyed `(pubkey, kind,
d-tag)`; a stray `h` tag must not channel-scope it.

The rest is import reflow plus replacing the guard test with a positive
one (`private_managed_agent_kind_is_owner_scoped_global_user_data`:
asserts UsersWrite scope, global-only, no h-channel scope).

## Why the guard test can be retired

The removed test
(`private_managed_agent_kind_remains_rejected_until_atomic_ingest_exists`)
pinned a stated precondition: *"must not enter generic EVENT ingest
before privacy and aggregate CAS deploy."* Both halves are resolved:

- **Privacy** — the author-only read gates for 30179 shipped to main
with #4593: `AUTHOR_ONLY_KINDS` membership, `req.rs` pre-filter + result
gates, `count.rs`, `event.rs` fanout, and the bridge pre-filter
(`bridge.rs:999-1000` returns `restricted: author-only kinds require
authors=[self]` / 403). Only the author can read the event back.
- **Aggregate CAS** — #4999 settled generation as **advisory**: the `g`
tag is shape-validated, never relay-enforced. Last-write-wins per
coordinate is the contract of record (see the kind:30179 contract blurb
in #4999), so no CAS mechanism is pending on the relay side.

## Why this is inert to existing relays and clients

- No production desktop code on main authors kind:30179 — the codec
(`private_managed_agent.rs`) has zero non-test callers. This PR accepts
a kind nobody can produce yet.
- Content is opaque NIP-44 ciphertext to the relay; the relay never
decrypts it.
- Reads remain author-only via the already-shipped gates above.
- Storage is the standard parameterized-replaceable path already
exercised by kinds 30175–30178. No schema, config, or migration changes.

## Testing

- Full `buzz-relay` package suite at this commit: 859 passed, 1 failed —
`api::mesh_demo::tests::demo_join_forwarded_arm_round_trips_echo` (504
vs 200), which **reproduces identically on clean main `769ac70b`** with
this change stashed; pre-existing/environmental, not introduced here.
- New positive ingest test passes.
- Pre-push hooks green (branch-skew, rust-tests, desktop-tauri-checks).

## Relationship to #4999

#4999 (relay-primary agent config, desktop half) stays DO-NOT-MERGE
pending live relay receipts + real CI; once this lands and deploys, its
live test simplifies to plain `desktop-standalone` against the real
relay, and #4999 rebases to drop its now-duplicate ingest hunk
(identical bytes → trivial rebase).

Originating thread:
buzz://message?channel=06f13ed3-0557-4ac2-922c-1545dd00bf97&id=2a43b3b4933a2ea78b77088619251c061355f9b7b6dc29ea0d702193f2344149


## Brownfield FTS note (review findings, operator-ruled non-blocking for
this PR)

Max and Sami independently identified that the FTS privacy skip-set is
regime-dependent: migration 0008 installs the positive allowlist (`kind
IN (0, 9, 40002, 45001, 45003)`) **only on an empty events table**; an
already-populated database keeps the 0001/0005 negative skip-list
(wrapped by 0014 to add 30350), which omits 30179 — so on such an
installation this PR admits 30179 rows whose NIP-44 ciphertext gets
indexed by `to_tsvector`. Sami measured both regimes against real
Postgres (brownfield: 30179 INDEXED; fresh: NULL) and demonstrated the
existing drift test only exercises the fresh regime.
`schema/schema.sql:222`'s canonical literal is also the negative list
and omits 30179. Migration dates put any relay deployed with data before
0008 landed (2026-07-13) in the brownfield class.

**Scope of exposure (Sami's trace):** not a content leak —
`event_visible_to_reader` / `is_author_only_event` gates hold on both
search surfaces (`req.rs:725`, `bridge.rs:1770`), so foreign readers
receive nothing. Lost is the storage-level NULL-tsv backstop plus FTS
page budget burned on post-filtered hits.

**Operator ruling (Tyler, events `1472e5b6`, `cbd368ed`):** ship this PR
without an exclusion migration. Safety argument that makes this sound
rather than merely accepted: main has **zero non-test 30179 writers**
until #4999's desktop half deploys — no 30179 rows can exist, so nothing
can be indexed in any regime while this PR is the only half live.



**Additional review characterizations (Sami, non-blocking, on the
record):**
- *Behavioral delta enumerated:* routing triple
(`required_scope_for_kind` / `is_global_only_kind` /
`requires_h_channel_scope`) compared for all 65,536 kinds at base
`769ac70b` vs head `77eeba6e` — exactly one row differs (30179). No
other kind or client changes behavior.
- *"SQL visibility before LIMIT" (NIP-PMA step 2):* no
`AUTHOR_ONLY_KINDS` pushdown clause exists in `buzz-db` (only
`SHARED_GATED_KINDS` has one). Author-only kinds are protected by the
pre-filter (`author_only_filters_authorized`) plus post-filter omission;
mixed-kind filters can burn candidate-page budget on discarded rows.
Pre-existing and identical for 30300/30350 — not introduced here; noted
so the NIP's step-2 checkbox is not read as fully ticked.
- *Envelope validation gap:* 30179 is the only parameterized-replaceable
kind at ingest with no per-kind envelope validator (codec grammar checks
run in the desktop writer, not the relay). Generic limits only (256 KiB,
±15 min, pubkey==identity, d-tag bound). Self-inflicted footgun bounded
to the author's own coordinate — candidate companion to the exclusion
migration in the #4999 rebase, deliberately not added here.

**Bound follow-up (required before/with the #4999 desktop half):** a
0014-shape additive migration (`pg_get_expr` capture + `CASE WHEN kind =
30179 THEN NULL ELSE (<existing>) END` wrap), add 30179 to the
`schema/schema.sql:221` literal, and a brownfield-regime variant of the
FTS drift test, per Sami's finding. Deploy-time spot check if ever
wanted: `SELECT pg_get_expr(d.adbin, d.adrelid) FROM pg_attrdef d JOIN
pg_attribute a ON a.attrelid = d.adrelid AND a.attnum = d.adnum WHERE
d.adrelid = 'events'::regclass AND a.attname = 'search_tsv';`

Signed-off-by: Tyler Longwell <tlongwell@block.xyz>
Co-authored-by: Eva <011987e296fd5006292d2f930b574be47c7801048d1983c46c425d3c95f0cffd@buzz.block.builderlab.xyz>
Co-authored-by: Tyler Longwell <tlongwell@block.xyz>
 2026-08-06 22:26:09 -04:00
Jordan Mecom
769ac70b74 fix(media): require authenticated reads (#4610) 
This change requires a valid signed Blossom authorization request and
current relay membership for every media GET and HEAD request. It
removes the unauthenticated compatibility path and updates desktop reads
to send the required authorization.

This blocks anonymous retrieval and access after relay-membership
revocation. It does not yet bind a blob to its originating channel, so
someone removed from a private channel can still read a known blob while
remaining a relay member. That channel-ACL follow-up remains required
before closing the full finding.

## Testing

- `git diff --check origin/main...codex/security-media-read-auth`
- Rebased onto `origin/main` at `5c98932`
- Full CI pending

Originating Buzz thread:
`buzz://message?channel=3928fe05-df61-4b5d-b9c7-d623b9b10ea1&id=3c6c02312f763fbe0d2bfc33a6c1a362f91d0354f3d18b039cf7a0558c1439d1`

---------

Signed-off-by: Jordan Mecom <jm@squareup.com>
Signed-off-by: Alex Rosenzweig <arosenzweig@squareup.com>
Signed-off-by: Eli Foster <efoster@squareup.com>
Co-authored-by: Eli Foster <efoster@squareup.com>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 00:46:42 +00:00
Taylor Ho
f03de210cd fix(desktop): preserve authoritative agent avatars (#4984) 
**Category:** fix
**User Impact:** Agent cards and catalog listings now show the avatar
belonging to the identity they represent.

**Problem:** Running agent cards could show a stale definition avatar
instead of the concrete agent profile, while adding another publisher's
catalog entry could let local edits repaint that publisher's listing.
This made agent identity look inconsistent across My Agents and the
Agent Catalog.

**Solution:** Treat the concrete agent pubkey profile as authoritative
for running-card avatars, with the linked definition as fallback. Keep
relay publications authoritative for foreign catalog presentation while
using local copies only for linkage and selection state.

| before | after |
|--|--|
| <img width="874" height="592" alt="Screenshot 2026-08-06 at 3 48
43 PM"
src="https://github.com/user-attachments/assets/2cc6c9f7-ea50-413c-9c7b-4d34bd8b4ec7"
/> | <img width="884" height="597" alt="Screenshot 2026-08-06 at 3 48
40 PM"
src="https://github.com/user-attachments/assets/b14a865c-65c4-458f-9c30-d1a557c877d7"
/> |
| agent-set avatar not showing | agent-set avatar is showing |

## Changes

<details>
<summary>File changes</summary>

**desktop/src/features/agents/lib/agentCardAvatar.ts**
Adds the explicit avatar precedence rule for running agent cards and
blocks avatar-dependent actions until the authoritative profile query
settles.

**desktop/src/features/agents/lib/agentCardAvatar.test.mjs**
Covers profile precedence, definition fallback, blank avatar handling,
and the profile-loading transition for linked-agent actions.

**desktop/src/features/agents/lib/personaCatalogRelay.ts**
Keeps publisher-provided catalog identity and behavior fields
authoritative after a local copy is added.

**desktop/src/features/agents/lib/personaCatalogRelay.test.mjs**
Verifies local copies contribute linkage and selection without
overriding publisher presentation.

**desktop/src/features/agents/ui/UnifiedAgentsSection.tsx**
Uses the concrete agent profile avatar before the linked definition
avatar on running-agent cards.

</details>

## Reproduction Steps

### Running agent card uses the agent profile avatar

Use two visibly different, publicly reachable image URLs: **A** for the
saved definition and **B** for the running agent profile.

1. In **Settings → Experiments**, enable **Agent-managed profiles**.
This prevents Desktop from restoring the definition avatar over an
agent's own relay-profile changes.
2. In **Agents**, create an agent with image **A** as its avatar and
start it.
3. In a channel containing that agent, ask it to update its own Buzz
profile avatar to image **B**. The exact CLI operation under the agent
identity is `buzz users set-profile --avatar <image-B-url>`.
4. After the agent confirms the update, reopen **Agents → My Agents**
(or reload the page so its kind:0 profile is fetched again).
5. Verify the running agent card shows image **B**, not definition image
**A**. Open **⋯ → Share** and verify the share flow also uses image
**B**.

Before this fix, the My Agents card and share flow preferred image **A**
whenever the linked definition had an avatar.

### Catalog listing remains publisher-authoritative

This scenario requires a second Buzz identity so the entry is foreign to
the account under test.

1. As the publisher identity, create an agent definition with a
distinctive name, avatar, and instructions, then use **Share → Share to
catalog**.
2. As the test identity, open **Agents → Discover agents**, find that
publication, and add it.
3. In **My Agents**, open the added copy's **⋯ → Edit**, change its
name, avatar, and instructions, and save.
4. Return to **Discover agents** and find the same publisher entry.
5. Verify it remains selected/added but still shows the publisher's
original name, avatar, and instructions—not the test identity's local
edits.

## Validation

- `pnpm test` — 4,376 passed
- `pnpm typecheck` — passed
- `pnpm check` — passed with existing non-error notices

---------

Signed-off-by: Taylor Ho <taylorkmho@gmail.com>
 2026-08-06 17:14:12 -07:00
Taylor Ho
67b77344d6 fix(desktop): next/back navigation during key creation onboarding (#4978) 
**Category:** fix
**User Impact:** Users can navigate back while an identity key is being
created, while Next remains visible and unavailable until creation
finishes.
**Problem:** The key-creation hold hid both navigation actions, leaving
users without an escape route or a clear indication of what would happen
next. **Solution:** Keep the onboarding footer mounted throughout
creation, leave Back enabled, and gate Next on the completed identity
state.

<details>
<summary>File changes</summary>

**desktop/src/features/onboarding/ui/BackupStep.tsx**
Keeps the onboarding navigation footer visible during key creation, with
Back available and Next disabled until the identity is ready.

**desktop/tests/e2e/onboarding-backup.spec.ts**
Covers the loading and completed navigation states so the intended
behavior cannot quietly crawl back out of the pit.

</details>

## Reproduction steps

1. Start desktop onboarding and choose to create a new identity.
2. Submit the profile step and observe the key-creation screen.
3. Confirm Back is enabled while Next is visible but disabled.
4. Wait for key creation to finish and confirm Next becomes enabled.


## Screenshots

| Before | After |
| --- | --- |
| Navigation actions are hidden during key creation. | Back remains
enabled while Next stays visible and disabled. |
| ![Before: key creation screen without navigation
actions](https://d24qwcpro867f5.cloudfront.net/repos/buzz/prs/4978/key-creation-before-bird.png)
| ![After: key creation screen with disabled Next and enabled
Back](https://d24qwcpro867f5.cloudfront.net/repos/buzz/prs/4978/key-creation-after-bird.png)
|

Signed-off-by: Taylor Ho <taylorkmho@gmail.com>
 2026-08-06 17:13:55 -07:00