fde-recall — pull relevant priors from the corpus
The read side of compounding. Lets the current engagement benefit from every past one, while the corpus stays client-anonymous.
Steps
- Take the user's question or the current deliverable
<type>as the query. - Read
.fde/corpus/<type>.yml(or all of.fde/corpus/*.ymlfor a broad question). Every entry is already anonymized (<CLIENT>,$<REDACTED>,<N>%) and carriessightingsandpaved. - Surface the 3-5 most relevant priors as patterns, not verbatim dumps,
and weight them by tier: a
pavedentry is hardened practice ("this held across 3+ engagements"), a ×2 is recurring, a ×1 candidate is one engagement's opinion — say which is which. - Hand off: suggest
/fde:draftto fold these into the current deliverable (where paved entries pre-fill and candidates become[candidate ×n — confirm]suggestions).
Hard rules
- Priors come from
.fde/corpus/only. Never read another engagement'sengagements/<other-client>/to answer a recall question — the corpus is the only legitimate cross-engagement source, because it is the only layer the anonymization gate guards. - If the corpus is empty (early days), say so honestly — there are no priors
yet, and the first
/fde:promoteis how that changes.