run_e3cfc77593ceeb9c

input

{
  "request": "Triage Jira ticket MZCLD-3746: Automate catalog validation and freshness enforcement so entries cannot silently rot",
  "references": [
    "https://mozilla-hub.atlassian.net/browse/MZCLD-3746"
  ],
  "sourceContext": {
    "issue": "MZCLD-3746"
  }
}

summary

MZCLD-3746 is a Backlog item proposing automated enforcement (CI validation on change, staleness detection, and owner-facing alerting) for the data catalog, to prevent the previously cleaned-up catalog from silently rotting again. It has no comments yet and explicitly calls out MZCLD-2189 (currently On Hold) as related prior work on BigQuery exports/adoption dashboards that could potentially be extended for freshness reporting instead of building a new mechanism. I attempted to pull MZCLD-2189 for context but access was blocked by policy (resource not in run subject), so that dependency check could not be independently verified in this triage pass and should be confirmed by a human/engineer with access.

findings

• Ticket is unrefined: status is Backlog, zero comments, no linked epic/assignee info visible, and no acceptance criteria beyond the three scope bullets — needs grooming before it can be estimated or sprint-planned.
• Scope has three distinct workstreams bundled into one ticket: (1) CI validation on catalog entity file changes to reject missing required fields, (2) staleness detection based on a review/update window, (3) alerting/visibility of validation and staleness failures to catalog owners. These are separable and may warrant splitting into sub-tasks for tracking and delivery.
• Ticket explicitly asks to check whether existing work in MZCLD-2189 (tenant/workgroup BigQuery exports + adoption dashboards) can be extended/revived rather than duplicating a freshness-reporting mechanism. This is a stated dependency/blocker-risk that should be resolved before implementation starts.
• Attempt to read MZCLD-2189 for corroborating context was blocked by tooling policy (resource not in run subject), so its current status/architecture could not be verified as part of this triage; the recommendation to check it remains unconfirmed.
• Stated rationale ties this work to the MVP goal of reducing hallucination risk, framing stale-but-present catalog data as more dangerous than missing data (confidently wrong owner/runbook links). This is a strong justification for prioritization but has no explicit priority/severity field set on the ticket.

proposed actions

Triage notes:

1) This ticket bundles three separable workstreams — (a) CI validation on catalog entity file changes, (b) staleness detection against a review/update window, (c) owner-facing alerting for both failure types. Suggest splitting into sub-tasks so each can be scoped/estimated independently, unless the team prefers to keep it as one epic-level story.

2) Before starting design/build, please confirm the status and architecture of MZCLD-2189 (currently On Hold) — it already has tenant/workgroup BigQuery exports and adoption dashboards that may be the right foundation to extend for staleness/freshness reporting rather than building a parallel pipeline. Recommend pinging the MZCLD-2189 owner to assess whether it can be revived, and note the outcome here to avoid duplicated effort.

3) Ticket currently has no priority set and is in Backlog with no acceptance criteria beyond the scope bullets. Given the stated MVP rationale (stale-but-present catalog data is worse than missing data for hallucination risk), recommend the team assign a priority and, if moving to a sprint, add concrete acceptance criteria (e.g., required-field list for CI validation, definition of the staleness window, and the alerting channel/owner-mapping mechanism).

tool calls

[
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "MZCLD-3746"
    },
    "result": {
      "key": "MZCLD-3746",
      "summary": "Automate catalog validation and freshness enforcement so entries cannot silently rot",
      "status": "Backlog",
      "description_text": "A one-time cleanup decays. Without enforcement, the catalog drifts back out of date and we lose the trustworthiness we just paid for \u2014 which is exactly what happened to the earlier sources of truth. Scope Validate on change  \u2014 CI checks on catalog entity files so a change that drops or omits a required field fails rather than merges. Detect staleness  \u2014 identify entries that have not been reviewed or updated within an agreed window, and surface them to their owners. Make failures visible  \u2014 validation failures and staleness should reach the catalog owner, not sit in a log. Relationship to existing work MZCLD-2189  (currently  On Hold ) already built tenant/workgroup data exports to BigQuery and adoption dashboards, which is the closest existing machinery to freshness reporting. Check whether that work can be extended or revived rather than building a parallel mechanism. Why this is in the MVP The stated goal is to reduce the probability of hallucinations. Stale-but-present data is worse than missing data for that purpose: a confidently wrong owner or a dead runbook link reads as authoritative to both an agent and an incident responder.",
      "comment_count": 0,
      "comments": []
    }
  },
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "MZCLD-2189"
    },
    "result": {
      "error": "read blocked by policy: resource not in run subject",
      "args": {
        "key": "MZCLD-2189"
      }
    },
    "blocked": true
  }
]

log