What you're trying to do
a KB has no declared audience. .vouch/ is as public as the repo it lives in
and as private as the machine it sits on, and nothing in the KB says which.
once subscriptions exist, that ambiguity becomes a real hazard: there is no
statement of intent to check a share against.
ditto declares it explicitly — private (default), specific handles, or public —
plus a "shared with you" inbox where incoming offers land, and public
"foundation graphs" anyone can subscribe to by handle.
What you've tried
- per-artifact
scope in scoping.py → the right mechanism one level down;
says nothing about the KB as a whole.
- repo visibility → a proxy at best, and wrong for a KB inside a private repo
that is meant to be shared with two collaborators.
Suggested shape
- a KB-level
visibility: private | allowlist | public in config, default
private, with an allowlist of KB ids or handles.
- incoming share offers surface where
inbox.py already surfaces dropped
files — one place a human looks for "things waiting on me" — and accepting one
is what creates a subscription.
vouch status reports visibility and current subscribers, so it is never a
surprise.
the interesting end state is a public foundation KB: a curated, cited,
review-gated body of knowledge that many projects subscribe to read-only. that
is the corroboration ratchet (.superpowers/CORROBORATION-RATCHET.md) arriving
from the product side rather than the protocol side, and it is a place vouch's
gate is a feature rather than a tax — a public ditto graph is unreviewed by
construction, a public vouch KB is reviewed by construction.
Compatibility considerations
additive; absent config means private, so no existing KB changes behaviour.
depends on read-only subscriptions landing first — visibility without
subscription is a declaration with nothing to enforce.
Alternatives
- rely on filesystem permissions — invisible to the tool, unenforceable across
a hub, and says nothing about intent.
- per-artifact scope only — every share becomes an artifact-by-artifact
decision; nobody will do that consistently.
part of the ditto-style track — see .superpowers/DITTO-STYLE-PLAN.md (T3.2).
What you're trying to do
a KB has no declared audience.
.vouch/is as public as the repo it lives inand as private as the machine it sits on, and nothing in the KB says which.
once subscriptions exist, that ambiguity becomes a real hazard: there is no
statement of intent to check a share against.
ditto declares it explicitly — private (default), specific handles, or public —
plus a "shared with you" inbox where incoming offers land, and public
"foundation graphs" anyone can subscribe to by handle.
What you've tried
scopeinscoping.py→ the right mechanism one level down;says nothing about the KB as a whole.
that is meant to be shared with two collaborators.
Suggested shape
visibility: private | allowlist | publicin config, defaultprivate, with an allowlist of KB ids or handles.inbox.pyalready surfaces droppedfiles — one place a human looks for "things waiting on me" — and accepting one
is what creates a subscription.
vouch statusreports visibility and current subscribers, so it is never asurprise.
the interesting end state is a public foundation KB: a curated, cited,
review-gated body of knowledge that many projects subscribe to read-only. that
is the corroboration ratchet (
.superpowers/CORROBORATION-RATCHET.md) arrivingfrom the product side rather than the protocol side, and it is a place vouch's
gate is a feature rather than a tax — a public ditto graph is unreviewed by
construction, a public vouch KB is reviewed by construction.
Compatibility considerations
additive; absent config means
private, so no existing KB changes behaviour.depends on read-only subscriptions landing first — visibility without
subscription is a declaration with nothing to enforce.
Alternatives
a hub, and says nothing about intent.
decision; nobody will do that consistently.
part of the ditto-style track — see
.superpowers/DITTO-STYLE-PLAN.md(T3.2).