Skip to content

docs(spec): proactive enrichment-recall subsystem#150

Open
jordanrburger wants to merge 1 commit into
mainfrom
upstream/enrichment-subsystem-spec
Open

docs(spec): proactive enrichment-recall subsystem#150
jordanrburger wants to merge 1 commit into
mainfrom
upstream/enrichment-subsystem-spec

Conversation

@jordanrburger

Copy link
Copy Markdown
Collaborator

Design review only — no behavior change. Adds a design spec; implementation follows once the approach is agreed. Companion to #149 (briefing-mode layer).

Context

A mature instance runs a pull-capture loop: at the end of a dreaming run it appends a small ranked set of "🧠 Help me remember …" questions to its wrap DM — facts no connector can see (in-person events, decisions, head-knowledge) — and feeds the answers back into the KB. The engine has none of it: no generator script, no phase, no state files.

Proposed design

  1. Port the generator as a tenant-agnostic cat-1 script (templates/scripts/generate-enrichment-questions.py, wired like the existing recurring-task-status.py). It's a pure-stdlib, read-only KB scanner that ranks connector-blind candidate questions and applies rotation (--exclude) + a persistent stoplist (--reject-file). The scanning logic is already generic; de-personalization is the work — comments, string literals, and one employer-specific regex guard.
  2. Seed empty state files install-only (enrichment-stoplist.txt, enrichment-qa-log.md) so upgrades never clobber a user's accumulated suppression/history.
  3. Add a recall section to phases/modes/feedback-processing.md (enrichment is the pull-capture half of the feedback loop) carrying the quality rules — user-only-answerable (not connector-answerable), no over-suppression to zero, self-containment — plus the rotation + in-thread-rejection loop.

Alternatives A (prose-only, no script — loses deterministic rotation/suppression) and B (no persistent state — loses permanent suppression) documented and rejected.

Asking reviewers

  • Is porting the script (vs prose-only) the right call?
  • The regex generalization — dropping the employer-specific connector-answerable guard without weakening head-fact discrimination — is the subtlest change; worth scrutiny.
  • The engine has no dedicated dreaming notification-composition phase; the recall attaches to feedback-processing.md. Acceptable, or worth a notification-phase consolidation first?

Spec: docs/superpowers/specs/2026-06-21-enrichment-recall-subsystem-design.md

🤖 Generated with Claude Code

…ber" loop)

Design spec (for review, not yet implemented) for upstreaming the proactive
KB-enrichment loop — the dreaming-run "🧠 Help me remember" block that asks the
user a small ranked set of connector-blind questions and feeds answers back into
the KB. None of it exists in the engine today (no generator script, no phase, no
state files).

Proposed design: port the read-only generator as a tenant-agnostic cat-1 script
(de-personalized — the scanning logic is generic, but comments/string-literals/one
employer-specific regex need scrubbing), seed empty install-only state files
(stoplist + qa-log) that survive upgrades, and add a recall section to
phases/modes/feedback-processing.md carrying the quality rules (user-only-answerable,
no over-suppression-to-zero, self-containment) + the rotation/rejection loop.
Alternatives A (prose-only, no script) and B (no persistent state) considered and
rejected. Flags the engine's missing dreaming notification-composition phase + the
regex-generalization risk for reviewers.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
jordanrburger pushed a commit that referenced this pull request Jun 28, 2026
Leaves only docs/specs/event-triggers.md in this PR. The enrichment-recall
and optional-connector-catalog specs are already under review as #150 and
#152 respectively, so they don't belong here.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant