Add triage-sentry-issues daemon

[charliecreates]

Summary

• Added a scheduled Sentry triage daemon at .agents/daemons/triage-sentry-issues/DAEMON.md.
• Based the routine on the linear bug-context pattern.
• Validated daemon configs successfully.

Resolves #358

✨ PR Description

Purpose: Add daemon specification for automated Sentry issue triage with release/repository context correlation and evidence-based commenting.

Main changes:

• Created DAEMON.md documentation defining triage candidate signals, high-signal issue selection criteria, and production-environment filtering rules
• Specified research policy requiring Sentry evidence, release context, and repository context gathering with materiality checks before posting updates
• Established comment format template with signal assessment, suspect releases/commits, ownership clues, and idempotent no-op behavior for unchanged evidence states

Generated by LinearB AI and added by gitStream.
_{AI-generated content may contain inaccuracies. Please verify before using.
💡 Tip: You can customize your AI Description using Guidelines Learn how}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 71.36%. Comparing base (e8a068c) to head (84a0868).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #359   +/-   ##
=======================================
  Coverage   71.36%   71.36%           
=======================================
  Files          18       18           
  Lines         674      674           
  Branches      202      202           
=======================================
  Hits          481      481           
  Misses        110      110           
  Partials       83       83           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[gitstream-cm]

✨ PR Review

The daemon definition is well-structured and includes clear idempotency rules and deny guards. A few gaps around operational scope, schedule timezone, and idempotency robustness are worth addressing before deployment.

3 issues detected:

🐞 Bug - No Sentry organization or project filter is defined, so the daemon has unbounded read and comment access across all visible projects.

Details: The daemon never specifies which Sentry organization(s) or project(s) it is allowed to operate on. Without an explicit allow-list, the agent could scan every project visible to whatever credentials it runs under, triggering unintended API usage, unexpected comment noise on unrelated projects, and potential data-access violations.

File: .agents/daemons/triage-sentry-issues/DAEMON.md (1-16)

🐞 Bug - Relying on a human-readable header string as the sole idempotency key is fragile and can be spoofed or missed, leading to duplicate or skipped triage updates. 🛠️

Details: The idempotency check (line 64) instructs the daemon to "inspect prior Charlie triage comments," but the comment format uses only a generic **Triage update** header with no unique machine-readable marker. Any person or bot that happens to post a comment starting with that string would satisfy the check, causing the daemon to skip a legitimate update. Conversely, if the daemon's own past comments ever differ slightly in phrasing, it may duplicate updates.

File: .agents/daemons/triage-sentry-issues/DAEMON.md (51-64)

_{🛠️ A suggested code correction is included in the review comments.}

🐞 Bug - No timezone is specified, so the effective run time is undefined and scheduler-dependent.

Details: The cron expression 0 10 * * 1-5 has no associated timezone. Depending on the scheduler's default (often UTC), this could fire at 10:00 UTC rather than the team's local business hours, making the triage output stale or poorly timed relative to developer standups.

File: .agents/daemons/triage-sentry-issues/DAEMON.md (4-4)

Generated by LinearB AI and added by gitStream.
_{AI-generated content may contain inaccuracies. Please verify before using.
💡 Tip: You can customize your AI Review using Guidelines Learn how}

[greptile-apps]

Greptile Summary

• Adds a new .agents/daemons/triage-sentry-issues/DAEMON.md daemon spec for scheduled Sentry issue triage.
• Defines weekday activation, candidate criteria, release/repository correlation guidance, and evidence-based update behavior.
• Adds a required Sentry comment format and no-op rules for avoiding unchanged triage updates.

Confidence Score: 4/5

The change is limited to a daemon specification, but the unclosed Markdown fence can cause the daemon to treat policy text as comment content.

The affected file is small and the issue is localized, with a straightforward fix to restore the intended split between the sample comment and operating instructions.

.agents/daemons/triage-sentry-issues/DAEMON.md

T-Rex Logs

What T-Rex did

• Verified the daemon descriptor could not be found at the base state and validation was ABSENT.
• Verified the daemon descriptor exists at head, frontmatter parses, all contract checks pass, and validation is PASS.
• Noted environment limitation where npm run check could not run because oxlint is not installed, so a fallback parser/check was used.

_{Ran code and verified through T-Rex}

_{Reviews (3): Last reviewed commit: "Apply suggestions from code review" | Re-trigger Greptile}

[greptile-apps]

Add Sentry scope

This scheduled daemon can select any high-signal Sentry issue that the integration can see. If Charlie has access to more than this repo's Sentry project, it can post triage comments on unrelated projects and correlate those issues with the wrong repository context. Add an explicit project, release, or repository match requirement, and no-op when that mapping is unavailable.

[greptile-apps]

Stabilize duplicate detection

The daemon runs every weekday, but the required comment format only stores free-form prose. When the same evidence is summarized with slightly different wording or link order, the next run has no stable key to compare and can post another equivalent triage update. Include a durable evidence marker, such as issue id, release, top frame, suspect commits, and trend bucket, and compare that before posting.

[greptile-apps]

Check all prior updates

The idempotency check only looks at prior Charlie triage comments, even though the deny rule says not to post an equivalent update when evidence has not changed. If a human, Sentry automation, or another daemon already posted the same evidence and next step, this daemon can still add a duplicate comment. The check should compare the current evidence state against recent relevant comments, not only Charlie-authored ones.

[chrisdoc]

@CharlieHelps this misses the watch condition, to watch for new sentry issues

[charliecreates]

Good catch — I missed that. I added an explicit watch condition for new Sentry issues in .agents/daemons/triage-sentry-issues/DAEMON.md and pushed the fix here: 84a0868

Also re-ran checks with bun run check (pass).

[gitstream-cm]

✨ PR Review

The daemon spec is well-structured and the deny/no-op rules are thoughtful. The three previously-identified issues (missing org/project allow-list, non-unique idempotency marker, and missing timezone on the cron) remain unresolved. One additional new issue was identified around the watch trigger.

1 issues detected:

🐞 Bug - A newly-created Sentry issue can never satisfy the high-signal candidate criteria, making every watch-triggered activation a guaranteed no-op that still burns API calls.

Details: The watch trigger fires on every new Sentry issue creation, but the candidate-signal criteria (lines 24–31) require established patterns such as "high or rising event volume," "repeated occurrences across sessions," and issues that are "unresolved or regressed." A brand-new issue has none of this history, so the watch-triggered run will almost always evaluate candidates, find the new issue unqualified, and no-op — while still consuming Sentry and repository API quota on every single issue creation event. For organizations with high error rates this could mean hundreds of spurious daemon activations per day.

File: .agents/daemons/triage-sentry-issues/DAEMON.md (5-6)

Generated by LinearB AI and added by gitStream.
_{AI-generated content may contain inaccuracies. Please verify before using.
💡 Tip: You can customize your AI Review using Guidelines Learn how}

[greptile-apps]

Cover regressed issues

The only watched Sentry event is new issue creation, but this daemon is meant to triage unresolved or regressed issues whose impact changes over time. When an existing production issue sharply worsens after a release, an event-scoped activation can miss it because no new issue was created. Make the daemon either purely scheduled so it scans unresolved high-signal issues each run, or include regression/worsening events in the trigger scope.

[greptile-apps]

Bound scheduled runs

The scheduled path does not define a checkpoint, lookback window, or per-run cap. On the first weekday activation, the daemon can treat every visible high-signal unresolved or regressed Sentry issue as in scope and post one comment on each issue. The existing idempotency rule only prevents repeats after a comment already exists, so it does not prevent an initial batch of comments across old backlog issues. Add a bounded discovery rule such as issues first seen or regressed since the previous successful activation, with a small fallback window and candidate limit.

[greptile-apps]

Coordinate duplicate posts

This daemon can run from both the weekday schedule and the new-issue trigger, but the posting rule only says to inspect prior comments before posting. If two activations handle the same issue at the same time, both can inspect before either comment exists and then both post equivalent triage updates. Require a final re-check or durable claim/evidence marker immediately before posting so concurrent activations cannot produce duplicate comments.

[gitstream-cm]

✨ PR Review

The daemon definition is well-structured with clear candidate signals, research policy, deny rules, and a machine-readable comment marker that resolves a previous idempotency concern. One structural defect was found that could affect how the agent interprets the document.

1 issues detected:

🐞 Bug - The markdown code fence opened at line 52 is never closed, causing the "## No-op behavior" section and its bullet conditions to be rendered as raw code rather than structured instructions.

Details: The fenced code block opened at line 52 (```md) is never closed with a matching ```. As a result, everything that follows — including the no-op criteria (lines 62–67) and the entire "## No-op behavior" section (lines 69–77) — is swallowed into the code block body. In rendered markdown these lines appear as literal code, not as behavioral rules. An agent parsing the rendered document could treat the no-op conditions as part of the comment template it should post rather than as execution-time guard clauses, causing it to paste the "No-op when…" block into every Sentry comment it creates.

File: .agents/daemons/triage-sentry-issues/DAEMON.md (52-77)

Generated by LinearB AI and added by gitStream.
_{AI-generated content may contain inaccuracies. Please verify before using.
💡 Tip: You can customize your AI Review using Guidelines Learn how}

[greptile-apps]

Close the format fence

The Markdown fence opened for the sample Sentry comment is never closed. That makes the idempotency/material-change rules and the whole no-op section part of the example comment body, so the daemon can include those policy lines in Sentry comments instead of treating them as instructions. Close the fence after the Evidence: line so the duplicate-check and no-op rules remain operative policy.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!