Sketches of where this could go. Some are partly built, some are pure intent. Listed for the reader who's thinking about adopting the pattern and wants to know which directions are well-explored vs untrodden.
Status legend:
- ⚙️ Partially implemented — there's a working prototype in our fleet
- 💭 Idea only — designed but not built
- 🚧 In active iteration
The current /graph page draws a project-level dependency view with dagre + @xyflow/react. The next version:
- Run
tree-sitterover each project to extract a function-level call graph - Cross-reference with the conversation history (which functions did Claude touch / discuss / refactor)
- Lay out with
dagrefor hierarchical or with force-directed for clustering - Cross-link to the BK knowledge entries that mention those functions
The hard part isn't the graph rendering — it's the cross-reference. You need stable identity for "function X in project Y" across a year of refactors.
10 expert team templates already exist as JSON (fullstack, security audit, refactor, data analysis, debug emergency, devops, content creation, UI design, business strategy, product planning). The current build fans them out sequentially.
v2:
- Plan the team's task tree in advance (one Opus pass)
- Distribute leaves to whichever host has the right context (e.g. the Docker host for container work, the GPU box for inference)
- Stream results back into one collapsible tree view
- Surface inter-agent disagreements as explicit "review needed" points
The replanning loop is the open question: when does one role's output invalidate another's?
Each project has its own CLAUDE.md and skills. Right now they're discovered at session start. The lock-in idea:
- A small UI panel that lists all skills/rules in scope for the active project
- Toggle them on/off explicitly before a session begins
- Persist the toggled set across sessions
- Optionally show a confidence score per rule (extracted from the Learning Center)
The goal is to make the rule set you're operating under legible instead of implicit.
Every Linear / GitHub issue has a "the conversation that led to this" trail. Right now those trails are in private Claude Code transcripts that nobody outside your machine ever sees. The integration:
- Hook into the chat completion signal — at end of session, optionally extract "what was decided" + "what's still open"
- Push to Linear/GitHub as comments on the issue ID mentioned in the prompt
- Reverse direction: opening an issue page shows the most-relevant prior conversations from BK
This is the lowest-cost way to share AI-assisted work with a team without exposing the raw transcript.
A pipeline that reads your Claude Code conversation history and surfaces:
- Recurring corrections you make ("don't mock the database", "match existing style")
- Successful patterns you've validated ("yes, exactly that approach")
- Project-specific knowledge that ought to be in CLAUDE.md but isn't yet
So far ~180 candidate rules have been auto-extracted from my own transcripts. The bottleneck is the review UI: rules need a thumbs-up/thumbs-down + a destination (which CLAUDE.md to inject into).
When a session approaches the model's context limit, the current behavior is opaque (autocompact summarizes, you lose detail). The handoff pattern:
- At ~80% context, extract a structured snapshot (current files in focus, decided plan, completed steps, open questions, active TODOs) — not a prose summary
- Open a fresh session pre-loaded with the snapshot + a pointer to the previous session_id
- Audit-trace which session decided what
The structured form survives compression better than prose.
Less ambitious, more fun: a thin always-on strip display showing:
- Active Claude sessions across the fleet (one icon per session, color = state)
- Solar panel state + battery SOC if your site has on-prem solar instrumentation
- Inbox count (Slack DMs, GitHub mentions)
Wall-mounted next to the monitor. Always-on, glance-able. Already partly built on a Pi 5.
- Multi-tenant SaaS-ifying it. This is internal infrastructure, single-tenant by design. Every assumption (one team, trusted LAN, the team owns the SSH keys) breaks if you tenant-ize it.
- Cloud-hosting it. Defeats the "local files, local SSH keys" point of the architecture.
- Productizing it. This repo is the product — the recipe — not the binary.
If any of these match your need, fork the idea and re-design from the constraint. The architecture in this repo is not the right starting point for them.