Skip to content

Conversation

@Claude
Copy link
Contributor

@Claude Claude AI commented Feb 11, 2026

Original prompt

This section details on the original issue you should resolve

<issue_title>Introduce .gbbcatalog.yml opt-in publication model and automated catalog lifecycle sync</issue_title>
<issue_description>

PR Objective

The goal of the IP catalog is to provide a structured, automation-driven, and reusable way to manage our Intellectual Properties (IPs) across GitHub repos.

Current issues:

  • Repos are created and left without governance.
  • Field cannot easily identify “best-in-class” solutions.
  • IPs can decay or become outdated.
  • Existing topic/visibility-based workflows are unreliable and error-prone.

This catalog specification introduces:

  • Explicit opt-in for catalog inclusion.
  • Cross-org reusable configuration.
  • Automation for validation, stale detection, and catalog syncing.
  • Clear ownership and lifecycle management.

1. Current Challenge

Today:

  • GBBs use a GitHub org (DevExpGBB) for IPs.
  • Some repos are private (team-only), some public (OSS-ready).
  • Inclusion in any catalog is ad hoc.
  • Visibility or topics are sometimes used as signals but are not reliable:
    • People may make repos public for testing, even if not ready.
    • Topic names can be inconsistent or typed incorrectly.
    • Lifecycle is not tracked.

We need a system that is:

  • Foolproof
  • Non-invasive
  • Explicit
  • Automated
  • Separate from visibility or experimentation

2. Publishing Model

A repository appears in the catalog only if:

  1. .gbbcatalog.yml exists in repo root
  2. catalog.enabled: true
  3. Metadata validation passes

Visibility (Private / Internal / Public) does not determine catalog inclusion.
Repos in WIP, under review, or public experimentation do not automatically appear in the catalog.


3. .gbbcatalog.yml Specification

Location: / .gbbcatalog.yml

Minimal Schema (v1)

schema_version: 1

catalog:
enabled: true # Required: true = include, false = exclude
owner: francesco.manni # Required: GitHub handle
display_name: "IP Name" # Required: human-friendly title
description: "Short summary" # Required: 1–3 sentences
maturity: incubating # Required: incubating | production | deprecated
last_reviewed: 2026-02-10 # Required: YYYY-MM-DD
review_cycle_days: 180 # Optional: default 180 days

4. Lifecycle Model

Catalog lifecycle is independent of repository visibility.

States

Condition Catalog State
No .gbbcatalog.yml Not in catalog
enabled: false Not in catalog
enabled: true Published / Ready
enabled: true + stale review (older than review_cycle_days) Needs Review
maturity: deprecated Deprecated

5. Automation Requirements

A GitHub Action ensures catalog integrity and lifecycle management automatically.

Trigger

  • Push to .gbbcatalog.yml
  • Scheduled weekly run
  • Manual workflow_dispatch

Responsibilities

  1. Validation

    • .gbbcatalog.yml must exist
    • Required fields present: enabled, owner, display_name, description, last_reviewed
    • enabled must be boolean
    • maturity must be one of incubating, production, deprecated
    • last_reviewed must be a valid date
    • If invalid, fail workflow and open issue tagging owner
  2. Catalog Sync

    • If catalog.enabled: true → add/update repo in central catalog index
    • If file deleted or enabled: false → remove repo from catalog
  3. Stale Review

    • If today - last_reviewed > review_cycle_days
      • Mark repo as “Needs Review” in catalog
      • Open issue tagging owner requesting metadata update
    • Workflow does not auto-remove repo

6. Non-Goals

  • Do not change repository visibility
  • Do not rely on repository topics for lifecycle
  • Do not enforce lifecycle via labels
  • Do not auto-archive repositories
  • Repo mutation limited to:
    • Opening issues
    • Updating central catalog index

7. GBB Guidance

  • Create IPs normally with the appropriate visibility for experiments
  • To publish in catalog:
    • Add .gbbcatalog.yml with enabled: true
    • Populate required metadata
  • Review cycle handled automatically via workflow
  • For deprecation: set maturity: deprecated in .gbbcatalog.yml
  • Optional workflow enhancement: “Submit to Catalog” button that generates .gbbcatalog.yml and opens PR for review

8. Benefits of This Model

  • Foolproof: no accidental catalog inclusion
  • Explicit ownership per IP
  • Separation of experimentation vs. catalog publishing
  • Automation enforces consistency
  • Detects stale IPs to prevent decay
  • Reusable across multiple orgs and repos
  • Scalable enterprise governance with minimal friction

9. Executive Summary

This model ensures:

  • Field sees curated, up-to-date solutions
  • GBBs can track and contribute safely ...

- Add validation script (validate-catalog.cjs) for .gbbcatalog.yml files
- Add fetch script (fetch-catalog-metadata.cjs) to retrieve catalog metadata
- Create catalog-sync.yml workflow for weekly sync and stale review detection
- Update refresh-data.yml to include catalog metadata fetching
- Add catalog metadata display in RepoCard component (maturity, owner, state)
- Update TypeScript types to include CatalogMetadata interface
- Create CATALOG_SPEC.md documentation for GBB users
- Add .gbbcatalog.yml.example template
- Create .gbbcatalog.yml for this repository as example
- Initialize empty catalog-metadata.json

Co-authored-by: francescomanni <72417313+francescomanni@users.noreply.github.com>
*/

const fs = require('fs');
const path = require('path');
@Claude Claude AI changed the title [WIP] Introduce .gbbcatalog.yml opt-in publication model Implement .gbbcatalog.yml opt-in catalog publication with automated lifecycle management Feb 11, 2026
@Claude Claude AI requested a review from francescomanni February 11, 2026 16:22
@francescomanni
Copy link

@claude[agent] this implementation is applicable just to asset type "code" (which is linked to repos) it will not impact other asset types.

@Claude Claude AI changed the title Implement .gbbcatalog.yml opt-in catalog publication with automated lifecycle management Addressing PR comments Feb 11, 2026
@francescomanni francescomanni requested a review from 0GiS0 February 11, 2026 16:31
@francescomanni
Copy link

@claude[agent] some corrections:

for last_reviewed we can use the repo last update date. If review is needed (last update > 6 months old)
Mark repo as “Needs Review” in catalog and enabled false - it needs to be removed
Open issue tagging owner requesting metadata update

Co-authored-by: francescomanni <72417313+francescomanni@users.noreply.github.com>
@Claude
Copy link
Contributor Author

Claude AI commented Feb 11, 2026

@claude[agent] some corrections:

for last_reviewed we can use the repo last update date. If review is needed (last update > 6 months old)
...

Done! I've implemented all three corrections:

  1. last_reviewed now uses repo last update date - The field is now optional. If not provided, the system automatically uses the repository's pushedAt (last commit push time) as the review date.

  2. Repos auto-disabled when stale - If a repository hasn't been updated in more than 6 months (or the configured review_cycle_days), it's automatically removed from the catalog by setting enabled: false.

  3. Issue creation for stale repos - The workflow still creates GitHub issues tagged with the owner when repos need review, so owners are notified to either push new commits or manually update the last_reviewed date.

Key changes:

  • scripts/validate-catalog.cjs: Made last_reviewed optional
  • scripts/fetch-catalog-metadata.cjs: Now fetches repo metadata and uses pushedAt date when last_reviewed is missing; auto-disables stale repos
  • CATALOG_SPEC.md: Updated documentation to reflect new behavior
  • Example files: Removed last_reviewed to show it's optional

Changes implemented in 1944bef.

@francescomanni
Copy link

@claude[agent] to avoid noise, make sure the notification is only sent to GBBs who own a repo that already contains the .gbbcatalog.yml file - ignore others from this lifecycle management.

Co-authored-by: francescomanni <72417313+francescomanni@users.noreply.github.com>
@Claude
Copy link
Contributor Author

Claude AI commented Feb 11, 2026

@claude[agent] to avoid noise, make sure the notification is only sent to GBBs who own a repo that already contains the .gbbcatalog.yml file - ignore others from this lifecycle management.

Done! The system now only processes and notifies owners of repositories that have opted into catalog lifecycle management by adding a .gbbcatalog.yml file.

Key changes:

  • Repos without .gbbcatalog.yml are completely ignored (no processing, no notifications)
  • Repos with .gbbcatalog.yml that become stale are included in catalog-metadata.json with state: 'needs-review' so owners can be notified
  • Stale repos are set to enabled: false so they don't appear in the catalog UI
  • Only owners who have explicitly opted in receive notifications

This avoids noise for repos that haven't joined the catalog system while ensuring proper lifecycle management for those that have.

Changes implemented in d3ecf21.

@francescomanni francescomanni marked this pull request as ready for review February 11, 2026 17:34
Copy link

@francescomanni francescomanni left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - I rely on @0GiS0 to understand the details

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.

Introduce .gbbcatalog.yml opt-in publication model and automated catalog lifecycle sync

2 participants