[refactoring] Extract cache-memory trending/history pattern into shared component

[github-actions]

Problem

7+ workflows use cache-memory for historical trending analysis, each implementing a similar pattern independently:

• Historical data collection windows (backfill vs. incremental)
• JSONL history file management
• Timestamp-based entry deduplication
• 7-day and 30-day trend calculations

This duplication leads to:

• Inconsistent trending logic across workflows
• Repeated prompt instructions (~40-60 lines each)
• Difficult to evolve the pattern (must update 7+ workflows)

Current State

Workflows using cache-memory for trending:

1. api-consumption-report.md - GitHub API quota trending
2. daily-cli-performance.md - Compilation benchmark trending
3. lockfile-stats.md - Lockfile statistics trending
4. chaos-pr-bundle-fuzzer.md - Fuzzing result trending
5. constraint-solving-potd.md - Constraint solver trending
6. daily-security-red-team.md - Security scan trending
7. static-analysis-report.md - Static analysis trending

Each workflow reimplements:

• History file path conventions (/tmp/gh-aw/cache-memory/trending/<name>/history.jsonl)
• Entry count checking before collection
• Backfill window logic (30-day initial load)
• Incremental collection (last 1-2 days)
• Deduplication by date

Proposed Solution

Create shared/cache-memory-trending.md with:

1. Standard data collection pattern

   • Check existing history entry count
   • If < 30 entries: run backfill window (30 days)
   • If >= 30 entries: incremental collection (1-2 days)

2. History file conventions

   • Path: /tmp/gh-aw/cache-memory/trending/<workflow-name>/history.jsonl
   • Format: One JSON object per line, with date field
   • Deduplication: By date (keep latest entry per day)

3. Trend calculation helpers

   • 7-day rolling average
   • 30-day rolling average
   • Percent change from previous period
   • Anomaly detection (>2 std dev from mean)

4. Chart generation guidance

   • Use shared/python-dataviz.md for visualization
   • Standard chart types for trends (line, bar, scatter)
   • Consistent color schemes

Migration Path

1. Extract pattern from api-consumption-report.md (most mature implementation)
2. Create shared component with configurable parameters (workflow name, metric names)
3. Migrate workflows one-by-one
   • Phase 1: api-consumption-report.md (validate extraction)
   • Phase 2: daily-cli-performance.md, lockfile-stats.md
   • Phase 3: Remaining 4 workflows

Example Usage

imports:
  - uses: shared/cache-memory-trending.md
    with:
      workflow-name: "api-consumption"
      metrics: ["core_consumed", "graphql_consumed"]
      trend-windows: ["7d", "30d"]
  - shared/python-dataviz.md
  - shared/otlp.md

Impact

• Workflows affected: 7+ (with room to grow as more workflows adopt trending)
• Line savings: ~40-60 lines × 7 = 280-420 lines
• Maintenance benefit: Single source of truth for trending logic
• Quality benefit: Consistent trend calculations and anomaly detection
• Adoption potential: Makes trending analysis easier for new workflows

References

• Example implementation: .github/workflows/api-consumption-report.md (lines 56-120)
• Chart integration: .github/workflows/shared/python-dataviz.md
• Analysis: §26206419572

Generated by 🔍 Workflow Skill Extractor · ● 1.6M · ◷

• expires on May 23, 2026, 5:08 AM UTC

[github-actions]

🍪 Issue Monster selected this for Copilot

I've identified this issue as a good candidate for automated resolution and requested assignment to the Copilot coding agent.

If assignment succeeds, the Copilot coding agent will analyze the issue and create a pull request with the fix.

Om nom nom! 🍪

🍪 Om nom nom by Issue Monster · ● 23.8K · ◷