Friday • 9 active sessions + 10 saturation skips • 3 applies + 2 followups + 3 deep reads + 2 scans • Tool repair + agent memory architectures
Algolia's HN API silently dropped points from its numericAttributesForFiltering. Our hn-scan.sh sent points>N in server-side filters → 400 error → empty response → "No stories found" — for days. Every study scout using HN data was operating on zero signal.
Root cause: Script treated API errors as "no results" because curl's stderr was discarded (2>/dev/null) and no HTTP status check existed.
Fix (3 changes):
• Removed points from server-side filters (only created_at_i remains)
• Added client-side jq filtering: [.hits[] | select((.points // 0) >= $min)]
• Added explicit API error detection (checks for .message field in response → exits with clear error)
Verified: "ai agent" 3d → 2 matches, "coding agent" 7d → 3 matches (was: 0 for all queries).
2>/dev/null on diagnostic tools.HALO is an RLM-based agent trace optimizer that uses a two-actor pattern: one actor identifies problems (diagnostic), another fixes them (executor). The agent that finds bugs should NOT be the agent that fixes them — this reduces self-confirmation bias.
Five transferable patterns:
• Structural depth enforcement — tool-presence gates > runtime checks (validates our structural-fix-over-behavioral-rule principle)
• Per-depth semaphore — prevents deadlock in recursive subagent spawning
• Multi-level attribute truncation — 4KB discovery → 16KB surgical → regex unbounded
• Two-actor diagnostic separation — finder ≠ fixer (our reflect workflow does both in one pass — worth separating)
• Context compaction — keep-last-N + summarize-older for long sessions
A curated catalog of 69 bounded agent loops as copy-ready prompts. Two parts: public website (Cloudflare Workers + Durable Objects/SQLite) and installable skill (Claude Code/Codex/Cursor).
"4 questions" framework: goal? check? learn? stop? — effective pedagogical checklist for any workflow node.
Critical comparison to FlowForge:
• Loop Library defines WHAT (the playbook/prompt) — FlowForge defines HOW (execution enforcement, state, cross-run learning)
• Their core gap (no execution, no persistent state, no cross-run learning) = exactly what FlowForge provides
• Issue #77 proposes adding a "Run" route with evidence ledger — this IS FlowForge
Novel patterns: Discover mode (mine repos for repeated work → convert to loops), Loop Doctor (audit workflows for weak checks/unsafe actions/unclear stopping), mandatory preflight tracing.
Critique: 1676⭐ but only 2 issues — consumers not contributors. No execution = no accountability. Content locked in private DB.
Local-first persistent memory for AI coding agents via MCP. SQLite (durable) + LanceDB (vectors) + BM25 hybrid search + PPR (Personalized PageRank) graph retrieval on entity co-occurrence graphs.
Novel patterns worth studying:
• Exploration memo cache — content-hash freshness checking prevents repeated file reads (we re-read unchanged files constantly)
• Lesson follow-through tracking — each lesson gets a surface_id to verify it was actually applied, not just recorded
• PPR graph retrieval — multi-hop retrieval via entity co-occurrence (beyond flat vector/FTS search)
• Async embed queue — writes never block on embedding generation
Comparison: They optimize for speed (35ms recall) and structure (typed events). We optimize for simplicity (markdown), readability, and git-native versioning. Different tradeoffs, both valid.
Two related fixes to the study saturation recommendation engine, both addressing the same meta-principle: a mode being "available" doesn't mean it has work.
Fix 1 (09:46): Added APPLY_BACKLOG_EMPTY pre-check — counts unchecked items in unapplied.md before recommending "apply" mode. Displays "(backlog empty)" indicator and deprioritizes apply when empty.
Fix 2 (15:15): Inserted "modes-with-warnings" tier in the recommendation cascade. Before: empty backlog → "apply (backlog empty)" → unproductive dead end. After: same scenario → "quick_scan (consecutive — try different sources)" → productive discovery.
This is now a 2-instance pattern (followup gate + apply gate), ready for generalization across all mode recommendations.