How does a public repo ledger resolve a parent ref that lives in a private ledger?

**ANSWERED 2026-07-30 by [dec-0011](dec-0011.md): candidate 1, opaque refs, with a three-state resolution.** The deciding argument was one this entry did not contain — candidates 2 and 3 both require superseding `cst-0003`, whose rule 3 already settles the adjacent case ("cites the **ref only**, never the text"), while candidate 1 is that rule applied consistently. The objection below about drift losing the "private parent I cannot see" distinction is dissolved by reporting three states (oriented / withheld / orphan) rather than two. Original text preserved below.

---

`kazi/.dira/entries/int-0001.md` carries `derives_from: sire:int-0002`. That ref is committed into a public repository, and `sire` is private. So a stranger cloning kazi sees a dangling pointer into a ledger they cannot read.

Three candidate answers, none obviously right:

1. **Opaque refs are fine.** The public ledger shows `sire:int-0002 (unresolved)`. Honest, leaks only the existence of a private parent and its id. Simple, but the orphan-drift flag can no longer distinguish "no parent" from "private parent I cannot see" for an outside contributor. 2. **Public alias entries.** The private parent gets a redacted public stub with a safe title. Resolves cleanly for everyone, but now the same intent exists twice and the two copies drift — and deciding what is "safe" is a judgment call made under time pressure on every write. 3. **Strip on publish.** Upward edges to private parents are omitted from what lands in the public repo. Maximally safe, but it makes every public repo ledger look like orphan work, which breaks the drift signal exactly where it is most useful.

Answering this requires deciding who the public `.dira/` is *for*. If it is for contributors, resolution matters. If it is documentation of the maintainer's reasoning that contributors merely read, (1) is sufficient and cheapest.

Blocking: the workspace tier cannot ship until this is settled.