tambo 0.10.1

Install and prove the whole AI knowledge-tool kit
Documentation
# The corpus

| tool | role in the box |
|---|---|
| quipu | governed knowledge-graph store |
| bobbin | semantic index · retrieval · RAG |
| camayoc | ontology bootstrap, ingress discipline, knowledge packs |
| yupana | code-structure graph — impact, callers, verify |
| desire-path | hallucinations → feature requests |
| shantytown | crew harness (multi-agent, tmux-resident) |
| shuttle | workflow engine — signed runs, windowed export, frozen history |
| creel | browser-native crew — tabs as workers |
| shanty | the tmux the crew lives in |
| seeds (`sd`) | work items as agent memory, stored in Quipu |

## Extending the corpus with Quipu shares

Every profile includes Quipu and can stage git-native knowledge shares into an
explicit local database:

```console
tambo plan --profile retrieval \
  --share ./team-knowledge \
  --share ./project-knowledge \
  --quipu-db ./knowledge.db
tambo apply --skip-install
```

A share directory is the canonical output of `quipu share`: `manifest.json`,
`export.nt`, and `shapes.ttl`. Tambo does not parse, rewrite, unpack, or wrap
those files. It invokes `quipu import <directory> --db <database>`, so Quipu
owns payload-hash verification, identity candidates, local SHACL validation,
and the staging/quarantine graph.

The returned `share_id`, graph, outcome, promotion eligibility, and blockers
are retained under `shares` in `.caboodle/state.json`. A quarantined import is
a successful safe consumption outcome that still needs review; Tambo never
runs `quipu import promote`. Promotion into ROOT remains a separate explicit
operator decision using the share ID.