refactor(desktop): rename agent config files to agent-config family - #2140
Merged
Merged
Conversation
Mechanical rename only — zero behavior change. Establishes one naming family for the canonical agent configuration surface ahead of the flag-reduction and per-agent-adoption work: - GlobalAgentConfigFields.tsx -> AgentConfigFields.tsx (canonical fields — not global-only; definition + instance scopes will consume it next) - GlobalAgentConfigEditor.tsx -> AgentDefaultsEditor.tsx (the wrapper that IS about defaults keeps the defaults name) - GlobalAgentConfigSettingsCard -> AgentDefaultsSettingsCard - AgentAiDefaultsDialog.tsx -> AgentDefaultsDialog.tsx - personaProviderModelFields.tsx -> agentConfigControls.tsx - personaDialogPickers.tsx -> agentConfigOptions.tsx (+ test file) Deliberately NOT renamed: - GlobalAgentConfig data type, tauriGlobalAgentConfig.ts, and the get/set_global_agent_config Tauri commands — the persistence layer really is global; renaming would cross the IPC/Rust boundary - data-testids (global-agent-*) — four e2e specs depend on them, including an onboarding spec - DefaultConfigStep.tsx — onboarding file, import lines updated only
baxen
approved these changes
Jul 19, 2026
tlongwell-block
pushed a commit
that referenced
this pull request
Jul 20, 2026
Main moved during CI (#2123, #2140). Resolves SettingsPanels.tsx conflict from the #2140 rename: GlobalAgentConfigSettingsCard is now AgentDefaultsSettingsCard; keep ActiveAgentCommunitiesSettingsCard alongside it in the agents section. Co-authored-by: Tyler Longwell <tlongwell@block.xyz> Signed-off-by: Tyler Longwell <tlongwell@block.xyz>
BradGroux
pushed a commit
to BradGroux/buzz
that referenced
this pull request
Aug 23, 2026
tucktuck101
pushed a commit
to tucktuck101/buzz
that referenced
this pull request
Sep 17, 2026
Serina's call, 2026-09-15: screen-content keeps emitting disposition redact for every roster-names candidate and gains an explicit requires-dispatch flag; the skill dispatches on that flag and drops ATTRIBUTION candidates from its own outcome. This is the only option that serves both consumers. A session following screen-sensitive/SKILL.md un-flags attribution names, satisfying block#2140. Anything reading screen-content's JSON directly still sees redact, preserving the fail-closed floor block#2110 established. Replacing redact with a neutral needs-dispatch disposition was rejected - it reintroduces the fail-open shape block#2110 closed five days earlier. STEP 7 now requires the retained redact and the new flag to fail the harness independently, so the fail-closed floor has its own coverage rather than sharing a test with the flag. Signed-off-by: test <test@example.com>
tucktuck101
pushed a commit
to tucktuck101/buzz
that referenced
this pull request
Sep 17, 2026
…d roster dispatch to the contract (block#2140) The interim paragraph said the dispatch 'does not exist yet'. After STEPs 1-3 it does, so it is gone and replaced by the real protocol. THE RETENTION RULE IS NOW A DEFAULT, NOT A LIST. screen-content reports every roster-names candidate as redact, and exactly one thing takes that away: a dispatch that COMPLETED and PARSED cleanly and returned ATTRIBUTION FOR THAT EXACT CANDIDATE. Every other outcome keeps redact and stays inside this skill's single combined outcome - never reported separately, never dropped. Both reviews flagged the earlier enumeration, and Codex round 2 showed why: an enumeration is a list of the failures someone thought of, so the one nobody listed is the one with no defined handling. Round 1's list omitted truncation; rather than add truncation to the list, the rule is now written so a new failure mode is covered the moment it exists. The named cases are instances of the default, and the file says so. Candidate identity now travels with the dispatch. Findings carry line-relative, zero-based, end-exclusive character offsets; match stays null because offsets are coordinates, not content. Those offsets go INTO the dispatch input and the verdict comes back against them - without that, a verdict earned by a contributor's name can be applied to an access-control entry beside it and the roster is silently unprotected. Also carried over from STEP 3's live dispatch: this gate sends the same four things verify-claims section 2 requires, and matches the response whole by section 2b's grammar. A verifier sent only a name and a sentence invents its own task and answers in a shape nothing can parse - demonstrated, not assumed. Step 2's combined-outcome paragraph updated to match: a candidate leaves step 1 either dropped by a clean ATTRIBUTION or carrying redact, and both states merge. The redact-handling text now points at the offsets as the only way to tell two candidates on one line apart. Verification: python3 launchpad/agents/the-professor/tools/check_professor.py --offline -> ALL NETWORK-FREE CHECKS PASSED. No occurrence of 'does not exist yet' or a live interim rule remains; block#2110 appears once, as resolved history. Not verified: procedure text. STEP 7 makes screen-content actually emit the flag and the offsets this step now depends on - until then the skill describes fields the tool does not yet produce. Signed-off-by: test <test@example.com>
tucktuck101
pushed a commit
to tucktuck101/buzz
that referenced
this pull request
Sep 17, 2026
…ffsets (block#2140) screen-content's roster-names finding carried a hardcoded message saying the $PROFESSOR_VERIFIER_CMD dispatch was "not yet built". Phase 1b builds it, so that message became false, and the finding carried nothing a skill could dispatch on. Three changes, per the 2026-09-15 decisions recorded in the plan: - `requires_dispatch: true` on every candidate. screen-sensitive/SKILL.md dispatches on the flag, not on the category name, so a consumer matching category strings cannot drift from what the script actually marks. - Line-relative column offsets alongside the line number, in Unicode characters, zero-based, end-exclusive. A finding carrying only a line number could not distinguish two candidates on one line, so an ATTRIBUTION verdict earned by a contributor's name could be applied to the access-control entry beside it. `match` stays null: offsets are coordinates, the matched name is content. - The message now names the dispatch a consumer has to run. `redact` is deliberately unchanged. A consumer reading this JSON directly never dispatches, and a disposition SKILL.md section 2 defines no action for is the fail-open block#2110 closed. Coverage: a new same-line fixture, because dispatch-roster-names-two-pairs.md puts its candidates on lines 11 and 16 and check_roster_names_multiple_candidates pins those numbers -- it cannot prove same-line candidates are distinguishable, and repurposing it would have deleted existing coverage. Reverting the flag alone, and the offsets alone, each fail the harness independently (verified in a scratch copy). Signed-off-by: test <test@example.com>
tucktuck101
pushed a commit
to tucktuck101/buzz
that referenced
this pull request
Sep 17, 2026
…n unit (block#2140) An independent Codex review of STEP 7 found no blocking defect but raised one real coverage gap, and one diagnostic that breaks the rule it asserts. The gap: the pinned unit is Unicode CHARACTERS, not bytes, and the same-line fixture was all ASCII -- so character and byte offsets were identical and a byte-counting implementation passed the test unchanged. The fixture's line 11 now carries an em dash between its two names: one character, three UTF-8 bytes. A byte implementation now reports (69, 82) for the second candidate where a character implementation reports (67, 80), and the failure message names that exact signature so the next reader is told which unit went wrong rather than just that two numbers differ. Verified by mutation: swapping the helper to count `.encode("utf-8")` lengths now fails the harness, where before it passed. The diagnostic: the `match is not None` assertion printed the offending value, and that branch fires exactly when the value is the matched name -- so the check that exists to keep content out of the JSON would have leaked it into a harness log. It now reports type and length and withholds the value. Mutation evidence, all three in a scratch copy: flag removed -> FAIL, offsets removed -> FAIL, offsets counted in bytes -> FAIL. Harness green otherwise. Signed-off-by: test <test@example.com>
tucktuck101
pushed a commit
to tucktuck101/buzz
that referenced
this pull request
Sep 17, 2026
…patch (block#2140) A page carrying an attribution name and an access-control roster name ON ONE LINE, plus a third candidate deliberately pointed at a verifier that cannot answer. All names synthetic placeholders, stated as such in the page. candidates in: 3 (raw screen-content output recorded BEFORE dispatch) candidates resolved: 3 in the final outcome: 2 [(11, 67, 80), (15, 24, 42)] dropped (ATTRIBUTION): 1 [(11, 14, 26)] Candidates 1 and 2 are on line 11, differ ONLY in their column offsets, and were resolved to OPPOSITE outcomes -- one dropped, one kept. Under the pre-STEP-7 finding shape they carried a line number and match: null and were indistinguishable; applying candidate 1's ATTRIBUTION verdict to candidate 2 would have removed protection from an access-control entry. That is the failure the offsets were added to prevent, now demonstrated rather than argued. "The attribution name is not flagged" is not vacuous here: it WAS flagged, as a candidate carrying redact, before dispatch resolved it. Candidate 3's dispatch returned prose with no recognisable verdict -- a parse failure -- and it RETAINED redact. Only a dispatch that completed and parsed cleanly and returned ATTRIBUTION for that exact candidate removes protection; every other outcome stays in the combined outcome rather than being reported separately or dropped, which would be block#2110's fail-open reappearing at the skill layer where the script's retained redact cannot reach it. The dispatch INPUT carries the name and its sentence; the dispatch RECORD does not. Each record identifies its candidate by line, offsets and returned verdict only -- screen-sensitive forbids a flagged span surviving into a log or a tool call's arguments, and recording it would breach the rule this step exists to demonstrate. Verified by grepping the records for every placeholder name and every given name in isolation: all absent. The script's floor is untouched: all three findings keep disposition redact, requires_dispatch true, match null. A consumer reading that JSON directly never dispatches and still sees three redacts. Signed-off-by: Serina Mcfall <serina.mcfall@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Mechanical rename of the agent-configuration UI files to one consistent
agent-confignaming family. Zero behavior change — 78 insertions / 78 deletions, all rename-symbol and import-path lines (verified: filtering those out leaves an empty diff). Lint clean, 3,180 unit tests pass,tsc --noEmitclean.GlobalAgentConfigFields.tsxAgentConfigFields.tsxGlobalAgentConfigEditor.tsxAgentDefaultsEditor.tsxGlobalAgentConfigSettingsCard.tsxAgentDefaultsSettingsCard.tsxAgentAiDefaultsDialog.tsxAgentDefaultsDialog.tsxpersonaProviderModelFields.tsxagentConfigControls.tsxpersonaDialogPickers.tsxagentConfigOptions.tsx(+ its test file)Why
This is PR 1 of the harness/provider/model config consolidation. The canonical config component (
GlobalAgentConfigFields) is about to be adopted by the per-agent definition and instance dialogs — at which point "Global" becomes actively wrong: the same fields will serve three scopes (global defaults, agent definition, agent instance). The naming rules:agent-config) so the canonical surface is discoverableDeliberately NOT renamed
GlobalAgentConfigdata type,tauriGlobalAgentConfig.ts, and theget/set_global_agent_configTauri commands — the persistence layer really is global-scoped; renaming would cross the IPC/Rust boundary for zero benefit.GlobalAgentConfigSaveResult(exported fromAgentDefaultsEditor.tsx) — kept intentionally: it wraps the IPC result, so the "Global" name honestly marks which side of the boundary it belongs to.data-testids (global-agent-*) — four e2e specs depend on them, including an onboarding spec; renaming them adds risk for no user value.DefaultConfigStep.tsx(onboarding) — import lines updated only, per the workstream's hard rule that onboarding doesn't change.check-file-sizes.mjsthat mention old names — they're changelog-style records of past allowlist bumps; rewriting history-describing comments would make them less accurate.Verification
pnpm exec biome check src tests— cleanpnpm test— 3,180 pass / 0 failtsc --noEmit— clean