Projects, channel-scoped bindings, and the automations/skills vocabulary#11
Merged
Conversation
…ndings to channels
…indings to channels
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
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.
Summary
Introduces Projects (a per-channel view of the agent, keys, skills, and automations bound to a channel) and makes the channel the single thing bindings attach to. Renames the user-facing vocabulary to industry terms: birds to automations, docs to skills, nests to projects. Reworks the sidebar so the four resource libraries (Agents, Skills, Keys, Automations) live behind one "Resources" tabbed item, cutting the persistent nav from nine items to six. Existing deployments keep working: the config-key rename is back-compat, and the binding-model change preserves any bindings already in the database.
Breaking changes
/api/birdsis now/api/automations, and/api/docsis now/api/skills. New binding writes accepttargetType: channelonly (existing non-channel rows are preserved, see migration notes).browserbird birdsis nowautomations(withflyrenamed torun), anddocsis nowskills.keys bindandskills bindtake<name> <channel>without the type argument./birdis now/automation, and itsflysubcommand is nowrun.BROWSERBIRD_BIRD_DATAis nowBROWSERBIRD_AUTOMATION_DATA.Migration notes (3 live deployments)
birds,docs, and*_bindingstables and their identifiers are unchanged. New bindings are channel-only, but existing bird-scoped key or skill bindings are preserved on both read and write, so nothing is dropped and the change is reversible.browserbird.jsonconfig keybirdsis renamed toautomations. Old files are read transparently and rewritten to the new key on the next config save, so no manual edit is required./birdto/automationby hand. Updating the manifest does not re-register the command on apps that are already installed.$BROWSERBIRD_BIRD_DATAin its prompt or scripts needs updating to$BROWSERBIRD_AUTOMATION_DATA. The directory it points to is unchanged, so existing data is preserved.Testing
tsc, eslint, prettier, 83 backend tests, and svelte-check (252 files) all pass. The test runner now also discovers top-level test files that were previously skipped. A review pass over the full diff surfaced and fixed a binding-edit regression (the channel-only write path used to reject any resource that still held a legacy bird binding) plus a few stale references. Both are covered here, the binding fix with a regression test.
Follow-ups (not in this PR)
bb-cliandbb-webchannels for conversations started from the web UI or CLI.