🦛 Hippo Memory Insights — 2026-05-28

[github-actions[bot]]

Summary

• Memories in store: 532
• New lessons learned from commits today: 0 (no fix/revert/bug commits in the last 7 days)
• Highest-confidence memory: mem_4afaa0965161 — stale .lock.yml files cause recurring CI friction (score=0.960, verified, retrieved 10×)

---

Top Memories Surfaced

1. mem_4afaa0965161 (CI, verified, score=0.960) — Stale workflow .lock.yml files cause churn and CI friction; run make recompile after markdown workflow edits.
2. mem_bf15fc906323 (CI, score=0.666) — validate-yaml job in .github/workflows/ci.yml scans all YAML files for ANSI escape sequences; violations fail early.
3. mem_bdc213856476 (CI, score=0.639) — CI WILL FAIL if make fmt / make build is skipped before commit — automatic and non-negotiable.
4. mem_54c981bfc72e (code quality, score=0.778) — skills/javascript-refactoring/SKILL.md provides the guide for splitting large JS files into separate .cjs modules.
5. mem_98f16a2f627c (code quality, score=0.735) — scratchpad/validation-refactoring.md holds the step-by-step validation refactoring guide and examples.
6. mem_ad0159793af4 (code quality, score=0.392) — Use typed string/int aliases to prevent accidental cross-type bugs (JobName ≠ StepID).
7. mem_cd9ed0b68bef (errors, score=0.571) — Diagnostic output (messages, warnings, errors) must go to stderr; structured output to stdout.

---

Suggested Improvements

Error Patterns

• Diagnostic routing regression risk — memories consistently flag that errors/warnings must go to stderr. Any new command or handler should be checked; a linter rule enforcing this would prevent future regressions.
• Stale .lock.yml files — the top verified incident memory shows this is a recurring problem. Consider a CI check or pre-commit hook that detects out-of-date lock files automatically.

Code Quality

• JavaScript file size — skills/javascript-refactoring/SKILL.md and scratchpad/validation-refactoring.md are both prominently recalled, suggesting JS/CJS files remain candidates for splitting. Review files >300 lines in .github/scripts/ and src/.
• Typed aliases underused — the memory store repeatedly surfaces the pattern of using Go typed aliases (type JobName string) to prevent cross-type misuse. Audit new struct fields that use bare string where a named type would add safety.
• Validation complexity — scratchpad/validation-refactoring.md exists precisely because validation logic has grown complex. Prioritise completing any outstanding refactoring steps documented there.

CI Health

• make recompile after workflow markdown edits — this incident has been encoded as a verified memory, meaning it has been hit more than once. A Makefile guard or README callout on the workflow editing process would reduce recurrence.
• make fmt / make build pre-commit — 5 CI failures in a single day attributed to skipped formatting. A git pre-commit hook running make fmt && make build would eliminate this class of failure entirely.
• ANSI sequences in YAML — validate-yaml catches these but failures are still occurring. Ensure editor configurations (.editorconfig, linting rules) strip ANSI before files are committed.

Quick Wins

1. Add make recompile reminder to workflow editing docs — low effort, eliminates a verified recurring incident.
2. Install a pre-commit hook for make fmt && make build — single-command setup, eliminates the most common CI failure class.
3. Prune 7 low-quality vague memories — run hippo audit --fix to clean up; reduces noise in future recalls.
4. Review JS files >300 lines — use the existing javascript-refactoring skill; each file is an isolated task.
5. Add a CI check for stale .lock.yml files — extend the existing validate-yaml job or add a dedicated step.

Longer-term Themes

• Validation architecture complexity — multiple high-confidence memories reference validation refactoring, suggesting this is an ongoing systemic effort rather than a one-off task. A dedicated work item tracking completion of scratchpad/validation-refactoring.md steps would help.
• Skill/agent decision overhead — the memory store has many entries about when to use skills vs. direct edits, indicating developers regularly lose time on this decision. Clearer heuristics or a concise decision flowchart in the README would reduce friction.
• Test-and-CI separation — memories consistently show make test is delegated to CI, but developers sometimes run it locally (slow, ~5 min). A lighter make test-unit (~3 min) path is documented; surface this more prominently.

---

Memory Health

• Total: 532 memories (532/532 embedded, up-to-date)
• Removed by decay: 0 this cycle
• Merged episodic → semantic: 79 (29 new semantic patterns created, 29 deduped)
• Shared to global store: 242 high-value memories promoted
• Low-quality memories to prune: 7 (all vague single-word fragments)

Low-quality memories flagged by audit

ID	Content
mem_650c0682ae4c	`.skill-optimizer/skill-optimizer.json`
mem_1dd58c2c0a93	**Rules:**
mem_dba94e928340	This command:
mem_b78c884146c7	` + WorkflowIDExplanation + `
mem_26217bf89737	**Implementation:**
mem_b168e03a0eca	**Avoid**:
mem_cd88fb9179d1	/tmp/gh-aw/cache-memory/investigation-2026-02-12-11-20-45-458.json

Run hippo audit --fix to auto-remove these.

References: §26561491045

Generated by 🦛 Daily Hippo Learn · sonnet46 786.7K · ◷

• expires on May 31, 2026, 7:44 AM UTC

[github-actions[bot]]

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

A newer discussion is available at Discussion #35885.