Problem
A user may keep two stores side by side: one shared with collaborators through a remote, one private. Nothing in the tool distinguishes them today, which allows three failure modes:
- Misrouted writes are unrecoverable. An agent can land a private note in the shared store. Once that commit is pushed, the note is in history permanently; deleting the file later does not unpublish it.
- Cross-store links disclose through their own filenames. A note in the shared store can link to one in the private store. Because a note's title tends to be the claim in these vaults, a dead wikilink leaks the claim even though the target is unreachable.
- Partial recall is silent.
kb-retrieve scoped to the shared store omits private siblings with no indication, so an incomplete answer reads as complete.
Skill-level guidance cannot close this. Skills are advisory prompts, and the sessions most likely to skip them are the ones already under context pressure. The write path into a shared store needs mechanical enforcement.
The consequences are also asymmetric: a note misrouted into a private store is merely inconvenient, while one misrouted into a pushed shared store is permanent. Only the shared-write path warrants enforcement.
Proposal
visibility: shared | private per store, declared in kb.yaml and/or .kb/config.yaml, defaulting to private. This is the enabling primitive the rest key off.- Writes to a
shared store require an explicit opt-in flag in kb-add and capture-event. This mirrors the existing --store @default design, where reaching the default is a deliberate act rather than what happens when a flag is forgotten.
- A
kb check rule rejecting links from a shared store into a private one, so it can run under lefthook and block the commit rather than reporting after the fact. It should also run in CI, so it applies to contributors who have not installed hooks locally.
- A
kb-retrieve helper field naming unsearched private siblings, so the skill can disclose partial recall instead of presenting a scoped answer as complete.
Out of scope
Content scanning -- regex or heuristics for personal names, customer names, or PII. It fails on exactly the novel case it would need to catch, and it manufactures confidence that makes the author careless. That is a net negative against having no scanner at all. Keep the judgment at capture time, where judgment actually exists.
Problem
A user may keep two stores side by side: one shared with collaborators through a remote, one private. Nothing in the tool distinguishes them today, which allows three failure modes:
kb-retrievescoped to the shared store omits private siblings with no indication, so an incomplete answer reads as complete.Skill-level guidance cannot close this. Skills are advisory prompts, and the sessions most likely to skip them are the ones already under context pressure. The write path into a shared store needs mechanical enforcement.
The consequences are also asymmetric: a note misrouted into a private store is merely inconvenient, while one misrouted into a pushed shared store is permanent. Only the shared-write path warrants enforcement.
Proposal
visibility: shared | privateper store, declared inkb.yamland/or.kb/config.yaml, defaulting toprivate. This is the enabling primitive the rest key off.sharedstore require an explicit opt-in flag inkb-addandcapture-event. This mirrors the existing--store @defaultdesign, where reaching the default is a deliberate act rather than what happens when a flag is forgotten.kb checkrule rejecting links from a shared store into a private one, so it can run underlefthookand block the commit rather than reporting after the fact. It should also run in CI, so it applies to contributors who have not installed hooks locally.kb-retrievehelper field naming unsearched private siblings, so the skill can disclose partial recall instead of presenting a scoped answer as complete.Out of scope
Content scanning -- regex or heuristics for personal names, customer names, or PII. It fails on exactly the novel case it would need to catch, and it manufactures confidence that makes the author careless. That is a net negative against having no scanner at all. Keep the judgment at capture time, where judgment actually exists.