proposal: Workflow Statistics & Automated Reporting#45
Merged
Conversation
eshulman2
reviewed
May 14, 2026
ekuris-redhat
force-pushed
the
forge-Jira-stats
branch
from
f1f7d6a to
cf92072
Compare
Introduces a proposal for two complementary features: - Per-ticket Jira summary posted at workflow completion (machine/human time split, token usage, revision counts, PR links) - Weekly status report aggregating across tickets, delivered via CLI, email (Gmail), and Confluence with historical trend charts Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Remove langfuse_trace_id (redundant — Langfuse groups by session_id=ticket_key) - Remove gate_timestamps and human time tracking - Remove review_rounds (use revision_counts["review"] instead) - Refocus primary metric on iteration counts as quality signal - Add --project flag for per-project report scoping - Mark CLI as admin-only (requires Redis access) - Change email recipients from env var to project-level config - Update per-ticket summary and weekly report formats accordingly Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Drop interim summary on blocked/failed (only post on completion) - Replace Confluence delivery with mailing list (self-subscribe) - Remove Phase 7 (Confluence integration) from implementation plan - Clarify admin owns cron scheduling, teams subscribe to mailing list - Remove time-based references from iteration analysis Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Always post full stats on blocked-due-to-escalation (not only when cost threshold exceeded) - Cost alert section appended when token threshold also exceeded - Remove per-project email config; recipients from Jira ticket only - Add on-demand /forge stats command and forge-watch stats CLI - Add per-ticket email to reporter/assignee on completion - Resolve container token capture via .forge/metrics.json - Remove Open Questions section (all resolved) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
ekuris-redhat
force-pushed
the
forge-Jira-stats
branch
from
8a68fd2 to
7f0dc07
Compare
danchild
reviewed
May 21, 2026
danchild
reviewed
May 21, 2026
|
|
||
| ## Summary | ||
|
|
||
| When a Forge workflow reaches a terminal state — successful completion, blocked, or unrecoverable failure — the system should automatically post a development statistics summary as a Jira comment on the Feature ticket. The primary quality signal is iteration count: how many manual interventions and corrections were needed at each stage. When a workflow is blocked due to escalation to human, the full stats summary is posted so the team can assess the work Forge completed before hitting the block. If token consumption also exceeds a configurable threshold, a cost alert is included. Users can request stats on demand for any ticket via `/forge stats` (Jira comment) or `forge-watch stats PROJ-123` (CLI). A per-ticket email with aggregate stats is sent to the ticket's reporter and assignee on workflow completion. Additionally, a weekly status report aggregates statistics across all active and completed tickets per project, delivered via admin CLI. |
Contributor
There was a problem hiding this comment.
Regarding the per ticket email, would we use a JIRA api to send this email?
I'm all for the weekly status reports, but we need to think carefully about how we are managing data in redis before enabling this featre. My guess is that we will not keep all historical data in redis - but instead purge the "old" data when it no longer needed. Obviously, unfinished issues will never be purged. The question becomes how long do we keep finished issues and related data around. The design will affect how we think about this weekly report (or even a monthly or yearly report if we're ambitious). On a related note, we should consider how we will archive old data so that it isn't lost but instead put in cold storage (I would recommend a configurable automated process to do this, but also to have a CLI tool to trigger ad-hoc archives)
danchild
reviewed
May 21, 2026
danchild
reviewed
May 21, 2026
eshulman2
requested changes
May 25, 2026
Address fourth round of review feedback: - Remove forge-watch stats (poller CLI, not part of production deployment) - Drop per-ticket email (Jira notifications already cover this) - Remove Phase 6 (email delivery) from implementation plan - Remove Gmail SMTP dependencies Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Weekly report posted as comment on a per-project report ticket (auto-created on first run, labeled forge:weekly-report) - Email sent to stakeholders via Jira notification API, recipients resolved dynamically from project roles (no static config) - CLI is on-demand, no cron scheduling - No SMTP infrastructure needed Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
eshulman2
requested changes
May 25, 2026
Revert proposal to the state before weekly report delivery and email changes were applied. Restores forge-watch stats, per-ticket email, and original report delivery section for further discussion. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…report email - Remove forge-watch stats (poller CLI, not part of production deployment) - Drop per-ticket email (Jira notifications already cover this) - Keep weekly report email delivery to stakeholders - Update implementation phases and dependencies accordingly Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Updated wording for clarity regarding cost alerts and token usage in the Jira workflow stats reporting.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Key design decisions
StatsStatemixin (no external dependencies)Related
Test plan
🤖 Generated with Claude Code