Files
AJ c6c6dfa5bc
CI / Lint (ruff) (push) Successful in 8s
CI / Tests (py3.10) (push) Successful in 9s
CI / Tests (py3.12) (push) Successful in 8s
docs: update HANDOFF.md — #1r done, next is #8 duplicate-name conflict
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-07-02 12:00:44 -04:00

5.5 KiB

HANDOFF — BCC feature backlog implementation

For the Claude Code agent working in this repo. Read this whole file, then CLAUDE.md, before touching code. A supervising Claude session watches this project through the Gitea MCP (issues, PRs, CI runs on git.avezzano.io), so keep all state in Gitea where it can be seen: issues for work items, PRs for changes, comments for decisions.

Step 0 — sync state

main may contain local commits that aren't on origin yet (the previous session couldn't push). Run git status / git log origin/main..main; if there are unpushed commits, push them first and confirm CI goes green before starting anything.

Step 1 — file the backlog as issues

Create one Gitea issue per item in the backlog table below (tea CLI or the API — you have full credentials). Prefix titles with the ID (e.g. "[#2] Stdio server spawn-test"). Create labels P0/P1/P2 first if they don't exist. Copy each item's full section from ../bcc-feature-requests.md (sibling of this repo folder) into the issue body — it has problem statements, evidence, proposed fixes, and acceptance criteria.

Corrections to that document — do not re-implement:

  • "Doc correction: README Claude Code path" — DONE (commit b16c0fd).
  • Item 1 (secret masking) — MOSTLY DONE (commit 6dee318): env/header values masked via delegate + Show-secrets toggle, Add-dialog password echo, diagnostics args redaction (redact_args). Only remainder: the warning badge when a secret-shaped value sits in args instead of env. File the issue scoped to just that.

Step 2 — work the backlog

Order ID Item Priority Notes
1 2 Stdio server spawn-test P0 Spawn with timeout, capture stderr; core logic in bcc_core (GUI-free, testable)
2 3 Backup restore UI P0 List .bcc_backups/, preview/diff, restore through normal atomic-write path
3 4 Stale-file protection P0 mtime/hash at load, re-check before write, prompt on conflict
4 1r Secret-in-args warning badge P0 Remainder of item 1; is_secret_key/_is_secret_value already exist in bcc_core
5 8 Duplicate-name conflict on paste/import P1 VERIFY FIRST: check paste_json/dropEvent in bcc.py for silent overwrite; file findings on the issue before coding
6 5 Cross-client support (Cursor/Windsurf/VS Code) P1 VS Code uses servers not mcpServers — needs a read/write adapter, not just paths
7 6 In-app MCP log viewer P1 Platform log paths in the doc
8 7 Windows MSIX path detection P1 Can't test locally on macOS — unit-test the detection logic, note that in the PR
9 9 Restart Claude Desktop button P1 Platform-specific process handling; scope to Desktop only
10 10 Server catalog / one-click add P2 Design pass first — post a proposal as an issue comment before building

Workflow rules

  • Branch per issue off main: feat/<issue-number>-short-slug (or fix/). One issue per PR. Reference the issue in the PR description (Closes #N).
  • Before every commit: python -m pytest (all green), ruff check ., ruff format .. CI enforces all three.
  • Conventional commits (feat:, fix:, test:, docs:, chore:) — match the existing history's style: body explains the why.
  • Merge only with green CI. If the supervising session has flagged something on the PR, resolve it before merging.

Architecture guardrails (violating these fails review)

  1. The cardinal rule: config writes only ever touch mcpServers and _disabledMcpServers. Every other key is preserved verbatim, in order. This matters extra for ~/.claude.json, which holds conversation history and project state.
  2. Core/GUI split: all logic in bcc_core.py (no GUI imports, unit- testable); bcc.py stays a thin PySide6 shell. New logic gets tests in tests/ — they run without PySide6, keep it that way.
  3. No new runtime dependencies without posting the justification on the issue first. PySide6 is currently the only one.
  4. Writes are atomic + backed up — route any new disk writes through write_config().
  5. Secrets never appear in diagnostics output or logs — use redact_args/ is_secret_key from bcc_core.

Current state (as of this handoff)

  • 92 tests in tests/test_core.py, ruff clean, CI = lint + pytest (py3.10/3.12).
  • main = ece049c (PR #16 merged). No unpushed commits.
  • Completed items: #2 (spawn-test, PR #11), #3 (backup restore UI, PR #14), #4 (stale-file protection, PR #15), #1r (secret-in-args warning, PR #16).
  • Next item: #8 — duplicate-name conflict handling. VERIFY FIRST: read paste_json and dropEvent in bcc.py to check whether pasting/dropping a server with a name that already exists silently overwrites it; file your findings as a comment on issue #8 before writing any code.
  • Recent features you should know exist: lenient JSON repair (repair_json_text, parse_pasted_json_verbose, repair_config_file + RepairDialog), ArgsEdit numbered gutter + split_suspicious_args, resizable splitters with QSettings persistence, secret masking, Claude Code profile at ~/.claude.json (settings.json only as "legacy" when it holds parked servers), backup restore UI (RestoreDialog, list_backups, backup_diff, restore_backup), stale-file protection (StaleDialog, config_mtime, external_change_summary).
  • GUI can't be smoke-tested in CI; note in each PR whether you ran python bcc.py locally and what you checked.