🦛 Hippo Memory Insights — 2026-06-25

[github-actions[bot]]

Summary

• Memories in store: 537
• New lessons learned from commits today: 2 new git-learned entries were recorded during this run, but they appear to be a duplicate pair for the same change: mem_555e2e92c437 and mem_14c7d96fff4b (#41392)
• Highest-confidence memory: mem_0324334270d0 — guard list_code_scanning_alerts prompts with state: open and severity: critical,high to avoid oversized MCP responses
• Consolidation status: hippo sleep partially progressed, but the run hit repeated database is locked errors on several commands; hippo embed succeeded and coverage is now 535/537 embedded

Top Memories Surfaced

• mem_0324334270d0 — Guard list_code_scanning_alerts calls with state: open and severity: critical,high
• mem_4afaa0965161 — Run make recompile after markdown workflow edits to avoid stale .lock.yml churn
• mem_e02072c9ae07 — Validate Node runtime / PATH early on GPU or self-hosted paths to avoid node: command not found
• sem_ef67ccfd978b — Use make agent-report-progress as the fast pre-PR validation gate
• sem_94dc733c4052 — Recompile workflows after .md changes to regenerate clean lock files
• sem_1a30ee0b98fb — Prefer selective tests over full package runs during development
• mem_555e2e92c437 / mem_14c7d96fff4b — today’s new learned lesson appears duplicated and should be deduplicated

Suggested Improvements

Error Patterns

• Overlarge code-scanning reads are a recurring prompt-design bug. The strongest retrieved memory is still mem_0324334270d0, which says workflow prompts must constrain list_code_scanning_alerts with state: open and severity: critical,high. Quick preventive action: audit prompts and templates that mention code scanning and make this filter mandatory anywhere alerts are queried.
• Workflow churn from stale lock files remains a repeated incident. mem_4afaa0965161 and sem_94dc733c4052 both reinforce the same failure mode: editing .github/workflows/*.md without running make recompile. Preventive action: keep explicit make recompile reminders in workflow-authoring docs and consider an audit/lint rule that fails when markdown workflow sources and generated lock files drift.
• Runtime assumptions still break some environments. mem_e02072c9ae07 shows a recurring node: command not found failure on GPU/self-hosted paths. Preventive action: validate declared runtimes and PATH earlier in workflow setup, especially in self-hosted or alternative-runner jobs.

Code Quality

• The memory store is dominated by imported guidance, not repo-specific observations. 527 of 537 memories are tagged imported, while only a small number are repo incidents or git-learned entries. That is useful context, but it makes high-signal local patterns harder to notice. A good cleanup target is pruning low-strength imported fragments that have decayed to stale confidence.
• Type/frontmatter guidance is a dense theme. Frequent tags include type-patterns-and-best-practices and frontmatter-configuration-types, suggesting repeated need for stronger typed configuration patterns in workflow/frontmatter code. Files under pkg/workflow/ and related config parsing paths are likely the highest-value places to keep paying down dynamic-typing debt.
• Testing guidance repeatedly favors selective execution. sem_1a30ee0b98fb and related testing memories suggest developers still burn time on broad test runs. This is more of a process/code-quality habit than a code bug, but documenting package-specific selective test recipes near touched packages would reduce iteration cost.

CI Health

• Validation sequencing is a stable health theme. sem_ef67ccfd978b and related checkpoint memories keep surfacing: use make agent-report-progress before shipping, and make fmt / make recompile when relevant. This suggests CI failures are still often caused by skipped local gates rather than deep product bugs.
• Hippo itself showed operational fragility today. Several required memory commands (learn --git, sleep, multiple recall calls) failed with database is locked, even though partial progress appears to have been written. That points to a workflow-health issue in the memory tooling path, likely around concurrent or overlapping DB access during daily runs.
• Embedding health is good; transactional robustness is not. hippo embed succeeded with 535/537 memories embedded, so retrieval infrastructure is mostly healthy. The bigger issue is command reliability under write/load contention.

Quick Wins

• 1. Deduplicate today’s duplicate learned memory pair. mem_555e2e92c437 and mem_14c7d96fff4b have identical content for #41392. This is a high-confidence, low-effort cleanup that will reduce noise immediately.
• 2. Add or tighten a guardrail for code-scanning prompts. Make the state: open + severity: critical,high filter a standard snippet in workflow prompts and relevant docs/templates.
• 3. Add a workflow-authoring check for stale generated locks. A light audit or test that detects .github/workflows/*.md edits without regenerated .lock.yml would directly address one of the only verified recurring incidents in memory.
• 4. Harden hippo daily-runner sequencing against SQLite lock contention. Even a simple serialized execution wrapper or retry/backoff around learn, sleep, and recall/export steps would likely improve today’s workflow reliability.
• 5. Prune decayed low-value imported memories. With 204 stale memories and many low-strength imported fragments, a targeted cleanup pass would improve signal-to-noise for future recalls.

Longer-term Themes

• Process errors outweigh code defects in the memory store. The most repeated themes are validation discipline, prompt scoping, workflow recompilation, and environment setup. That suggests the repo’s biggest gains may come from stronger automation and guardrails, not just more tests.
• Workflow authoring remains the main reliability surface. Recompile discipline, code-scanning prompt limits, and runtime declaration issues all point to the same systemic area: agentic workflow authoring and generated Actions hygiene.
• Memory quality management needs its own maintenance loop. The store has healthy volume, but also 204 stale entries and at least one obvious duplicate from today. As the store grows, dedup/pruning quality will matter as much as adding new memories.

Memory Health

• Current status from hippo status: 537 total memories, 204 stale, 215 at-risk (strength < 0.2), 0 open conflicts, 535/537 embedded.
• The most obvious duplicate is today’s pair: mem_555e2e92c437 and mem_14c7d96fff4b.
• The store remains heavily skewed toward imported guidance (527 memories tagged imported), so pruning low-strength imported fragments would likely improve recall quality.
• Because hippo list is not available in this build and several commands hit database is locked, memory-health conclusions should be treated as directionally correct but operationally incomplete.

Operational notes from this run

• mcpscripts hippo --args 'learn --git' failed with Error: database is locked.
• mcpscripts hippo --args 'sleep' also ended with Error: database is locked, but stdout reported: 1 new lessons added, 0 duplicates skipped. Auto-learned 1 lessons from today's git commits.
• mcpscripts hippo --args 'embed' succeeded: 0 new embeddings created. 535/537 total.
• Several recall commands also failed with database is locked; analysis above uses the successful outputs from status, one successful recall, and the full export payload.

Generated by 🦛 Daily Hippo Learn · 47.3 AIC · ⌖ 13.2 AIC · ⊞ 3.6K · ◷

• expires on Jun 27, 2026, 11:34 PM UTC-08:00

[github-actions[bot]]

This discussion has been marked as outdated by Daily Hippo Learn.

A newer discussion is available at Discussion #41632.