Busabase × Paseo
Knowledge Base for Paseo
Keep independent analyses distinct until the evidence settles them
Paseo runs coding agents across providers and worktrees. Keep its native handoff for files, progress and constraints; use Busabase for accepted investigation conclusions that another provider or task needs to cite. A handoff can carry an open question without turning it into a team decision.
Busabase product interface (English).
Keep execution handoff and shared conclusions in their own places
Worktree files and diffs describe the implementation in progress. A native handoff describes progress, constraints and the next action. A Busabase investigation record describes a claim that another task may rely on, with its source and acceptance state. Link these artifacts instead of duplicating the entire working context into a knowledge record.
Execution context
Keep working files, instructions and temporary observations with the task.
Evidence references
Preserve the source, observation time and exact scope that support a claim.
Accepted team record
Carry reviewed values and unresolved questions into the next task through a current record reference.
Two explanations for dropped WebSocket connections
In an illustrative investigation, agent A suspects a proxy idle timeout and agent B suspects an event-loop stall. Neither diagnosis is accepted merely because a lead agent synthesizes them. Store each claim with its evidence, then run checks that discriminate between them. Code fixes remain in Git diffs and pull requests.
Illustrative example, not a real customer result or test.
Example proposal ledger
| Field | Illustrative value | Evidence / decision |
|---|---|---|
| claim.A | proxy idle timeout | hypothesis |
| claim.B | event-loop stall | hypothesis |
| evidence | logs from matching time window needed | missing |
| accepted_record | empty until discriminating check | not accepted |
- 01A: proxy timeout — unverified
- 02B: event-loop stall — unverified
- 03discriminating check — not run
- 04accepted finding — empty until review
Turn competing diagnoses into a verification plan
For the WebSocket case, preserve the disconnect timestamps, proxy configuration and event-loop observations separately. Assign a next check that can distinguish the hypotheses. If only one environment reproduces the failure, accept the result for that environment; link the code PR as implementation evidence rather than treating a merged PR as proof of every causal claim.
What the next agent should receive
Suggested record fields
case_id, provider, source_agent, claim, evidence, open_question, accepted_record, head
Install and verify access on the daemon host and in each underlying CLI. A phone or browser client is not the installation host. Switching from Claude Code to Codex does not prove both have the same tools or identity. Independent opinions are evidence inputs, not a majority-vote approval mechanism.
Source + observation time
Link the exact file, row, commit or URL and state when it was inspected.
Scope + acceptance state
Name the environment or delivery affected; keep unsupported fields unresolved.
Owner + next check
Assign who maintains the conclusion and what evidence would require revisiting it.
From a finding to an accepted record
- 01Read the existing record and verify Space, Base and head.
- 02Propose only supported fields; include evidence and unresolved questions.
- 03Use changeRequest permission when review must precede acceptance. A write grant is broader authority, not a mandatory human gate.
- 04After authorized review and merge, read the canonical record back. Carry its version and open questions into the next task.
Make a provider switch an explicit handoff
The receiving agent reads the accepted finding, its scope, the linked evidence and the remaining question before continuing. Confirm access on the daemon host and the chosen CLI. A different provider may have different tools; if it cannot inspect the evidence, leave that verification step open and delegate it explicitly.
Practical questions
Does provider agreement approve a conclusion?
No. Keep each provider’s claim and evidence distinct. Review the discriminating check and its result, then accept only the supported conclusion. Agreement can help prioritize a check; it does not replace one.
Does this replace native memory?
No. Keep native instructions and session memory for execution. Store reviewed facts and their sources here, and read their current version when needed.
How do concurrent updates work?
Read the current head before proposing. If it changes, inspect competing edits and revise the proposal rather than overwriting new evidence.