Skip to content

Implement automated catalog maintenance system#20

Draft
Claude wants to merge 2 commits intomainfrom
claude/automate-catalog-maintenance
Draft

Implement automated catalog maintenance system#20
Claude wants to merge 2 commits intomainfrom
claude/automate-catalog-maintenance

Conversation

@Claude
Copy link
Contributor

@Claude Claude AI commented Feb 5, 2026

Adds lifecycle management automation to minimize manual catalog maintenance. Content owners receive automated reminders when their IP entries haven't been updated in 90+ days, with escalation for critical staleness (180+ days).

Changes

Content Schema (src/content/config.ts)

  • Added owner field for GitHub handle/email
  • Added status enum: wip | ready | deprecated
  • Added last_updated date field for staleness tracking

Staleness Detection (scripts/check-staleness.js)

  • Parses IP content frontmatter
  • Calculates days since last_updated
  • Generates JSON report with severity levels (medium/high/critical)
  • Exits with status code 1 when stale content found

Automated Notifications (.github/workflows/catalog-maintenance.yml)

  • Runs weekly (Monday 9 AM UTC)
  • Creates GitHub issues for stale entries
  • Auto-assigns issues to content owners
  • Updates existing issues with reminder comments

Documentation (CATALOG_LIFECYCLE.md)

  • Lifecycle rules and thresholds
  • Owner responsibilities
  • Team ritual suggestions

Usage

Content entries now support lifecycle metadata:

---
title: "Your Content"
owner: "@githubhandle"
status: "ready"
last_updated: 2026-02-04
---

Run manual staleness check: node scripts/check-staleness.js

All fields are optional for backward compatibility. Existing content continues to work without modification.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

  • telemetry.astro.build
    • Triggering command: /home/REDACTED/work/_temp/ghcca-node/node/bin/node node /home/REDACTED/work/devexpgbb.github.io/devexpgbb.github.io/node_modules/.bin/../astro/astro.js build git rev-�� --abbrev-ref HEAD ndor/bin/git (dns block)
    • Triggering command: /home/REDACTED/work/_temp/ghcca-node/node/bin/node node /home/REDACTED/work/devexpgbb.github.io/devexpgbb.github.io/node_modules/.bin/../astro/astro.js build base64 exit�� "args":["/home/REDACTED/work/_temp--abbrev-ref nux-x64/bin/esbuild /usr/local/sbin/git (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

Original prompt

This section details on the original issue you should resolve

<issue_title>Automated Catalog Maintenance</issue_title>
<issue_description>As a team member
I want catalog population and updates to be automated
So that manual maintenance is minimized and regular team rituals encourage review and presentation of new IP:

The team discussed automating lifecycle management for catalog assets, including sending notifications to owners when their IP has not been updated for a set period (e.g., three months), prompting them to review and update the content. 1
The process would involve tracking asset status (work in progress, ready for catalog, deprecated) and using labels or metadata to manage this. 2
Owners would receive reminders (such as email or issue creation) to check if their asset is still relevant or needs updating, ensuring the catalog remains current. 3
The approach aims to minimize manual maintenance and keep the catalog accurate, with the responsibility for updates resting on asset owners. 4

Technical Requirements

I couldn’t update the issue due to a tool error. If you want me to retry adding the plan to the issue, please confirm and I’ll proceed.

Here’s a detailed plan you can add to issue #11:

Research summary (concepts to leverage)

  • Lifecycle metadata & ownership: track asset status (WIP/Ready/Deprecated) and owner contact in front‑matter or a catalog metadata store.
  • Staleness policy: “stale after N months” with reminders, escalation, and eventual deprecation.
  • Automation hooks: scheduled checks via GitHub Actions + notifications (issue creation, email, or Slack).
  • Human review loop: recurring team ritual for review/demo of newly updated assets.

Proposed plan

1) Define catalog metadata & lifecycle

  • Add/standardize metadata fields for each asset (front‑matter or data file):
    • owner (GitHub handle/email)
    • status (wip, ready, deprecated)
    • last_updated (ISO date)
    • review_due (computed or stored)
  • Document lifecycle rules in a short CATALOG_LIFECYCLE.md:
    • When assets move between statuses
    • Update expectations and responsibilities

2) Choose automation mechanism

  • Use GitHub Actions on a scheduled cron:
    • Parse catalog metadata
    • Identify assets stale beyond threshold (e.g., 90 days)
    • Notify owners
  • Notification methods (pick one or multiple):
    • Create GitHub issues assigned to owners
    • Post to team Slack (webhook)
    • Email (if supported/allowed)

3) Build the staleness detection workflow

  • Implement a script (Node/Python) to:
    • Read all catalog entries
    • Compute “stale” based on last_updated
    • Generate a report artifact (CSV/JSON)
    • Trigger notifications

4) Automate reminders & escalation

  • First reminder: when stale threshold reached
  • Second reminder: 2–4 weeks after first
  • Escalation: notify team lead or apply needs-review / stale label
  • Auto‑deprecate after 6 months stale (optional)

5) Update catalog UI/UX (optional)

  • Display status and last_updated in catalog
  • Add badges for stale/needs-review
  • Filter by status or review due date

6) Team ritual integration

  • Monthly/biweekly review:
    • Review new/updated assets
    • Confirm deprecations
    • Celebrate new IP entries

7) Rollout plan

  • Phase 1: metadata standardization + documentation
  • Phase 2: staleness script + scheduled workflow
  • Phase 3: notifications + team ritual
  • Phase 4: optional UI enhancements + escalation

8) Success criteria

  • ≥90% assets have owner, status, last_updated
  • Automated reminders sent on schedule
  • Reduction in manual catalog maintenance effort
  • Regular review cadence established

If you confirm, I’ll retry adding this plan directly to issue #11.</issue_description>

Comments on the Issue (you are @claude[agent] in this section)

Co-authored-by: ewega <26189114+ewega@users.noreply.github.com>
@Claude Claude AI changed the title [WIP] Automate catalog population and update processes Implement automated catalog maintenance system Feb 5, 2026
@Claude Claude AI requested a review from ewega February 5, 2026 14:52
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.

Automated Catalog Maintenance

2 participants