feat(triage-bug): add persistence-impact analysis to Step 3

[mrizzi]

Summary

• Add persistence-impact analysis sub-step to triage-bug Step 3 (Codebase Investigation) that traces buggy function output to database write operations
• When a persistence boundary is found, Step 5 (Generate Task) now includes guidance for adding a data migration to correct existing persisted data
• Add eval scenario (id 7) with mock fixtures to test the persistence-impact analysis flow

Implements TC-5363

Test plan

• Verify the new persistence-impact sub-step in Step 3 reads correctly and follows existing SKILL.md conventions
• Verify the data migration guidance in Step 5 covers Files to Create, Implementation Notes, and Acceptance Criteria
• Run eval 7 to confirm the persistence-impact analysis flow produces correct task output
• Verify existing evals 1-6 still pass (no regression)

Summary by Sourcery

Add persistence-impact handling to the triage-bug workflow and introduce a new eval scenario to validate it.

New Features:

• Extend triage-bug Step 3 with a persistence-impact analysis sub-step that traces buggy function outputs to database write operations.
• Augment triage-bug Step 5 so generated tasks include data migration guidance when buggy outputs are persisted.

Tests:

• Add a new persistence-impact eval scenario with mock repository and bug issue fixtures to exercise the updated triage-bug flow.

[sourcery-ai]

Reviewer's Guide

Adds a persistence-impact analysis sub-step to triage-bug Step 3 and corresponding data-migration guidance in Step 5, plus a new eval scenario and mock fixtures to validate the new flow.

Flow diagram for new persistence-impact analysis and data-migration guidance

flowchart TD
  A[Step 3: Identify buggy function] --> B[Persistence-impact analysis]
  B --> C[Trace callers with find_referencing_symbols or Grep]
  C --> D{Persistence boundary found?}
  D -- Yes --> E[Record table and column]
  E --> F[Record write location file and symbol]
  F --> G[Classify write as ingestion_time or per_access]
  G --> H[Carry persistence impact details to Step 5]
  H --> I[Step 5: Add data migration Files to Create]
  I --> J[Step 5: Add migration Implementation Notes]
  J --> K[Step 5: Add Acceptance Criteria for corrected records]
  D -- No --> L[Output is computed at query time]
  L --> M[Proceed to Step 4 and Step 5 without data migration]

Loading

File-Level Changes

Change	Details	Files
Extend triage-bug Step 3 with a persistence-impact analysis sub-step that traces buggy function outputs to database write operations and records persistence details for later steps.	Introduce a new "Persistence-impact analysis" subsection under Step 3 explaining how to determine whether buggy function output is persisted vs computed at query time. Define a tracing workflow using find_referencing_symbols or Grep to follow call chains from the buggy function to potential database write operations. Specify what information to capture when a persistence boundary is found, including table/column, write location, and ingestion-time vs per-access write behavior. Clarify behavior when no persistence boundary is found, explicitly stating that no data migration is needed. Provide a concrete example trace from a function through intermediate callers to a final insert operation marking the persistence boundary.	plugins/sdlc-workflow/skills/triage-bug/SKILL.md
Update triage-bug Step 5 to include explicit task-generation guidance for data migrations when persistence impact has been identified.	Add a "Data migration (when persistence impact is flagged)" subsection under Step 5 describing when a migration must be included in the generated task. Detail how to identify correct migration file naming, location, and format based on existing repository migration patterns using search_for_pattern or Grep. Describe the required Implementation Notes content for the migration, including target table/column, recomputation logic, and alignment with existing migration conventions. Specify an additional Acceptance Criteria item asserting that incorrect persisted records are corrected by the migration.	plugins/sdlc-workflow/skills/triage-bug/SKILL.md
Introduce a new persistence-impact evaluation scenario with mock repository and bug issue context to exercise the new analysis flow.	Add a synthetic mock repository context file modeling a buggy risk-score computation whose result is persisted at ingestion time via Diesel ORM inserts, including schema and migration directory layout. Document an existing test that unintentionally passes despite the bug, clarifying why additional coverage is needed for non-trivial cases. Add a synthetic mock Jira bug issue file describing the risk-score bug, reproduction steps, and expected vs actual outcomes to drive the eval scenario. Register the new eval scenario (id 7) in the triage-bug evals configuration to use the new mock context and bug issue files.	evals/triage-bug/evals.json evals/triage-bug/files/repo-context-persistence-mock.md evals/triage-bug/files/bug-issue-persistence-impact.md

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've left some high level feedback:

• In the new persistence-impact analysis step, consider adding guidance for cases where the buggy function has multiple callers that persist its output to different tables/columns (or both ingestion-time and update-time writes) so the workflow is clear about how to prioritize or handle multiple persistence boundaries.
• In the data migration section of Step 5, it may help to specify what to do when a repo has more than one migration style (e.g., raw SQL and ORM helpers) so the implementer knows which convention to follow when creating the new migration.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- In the new persistence-impact analysis step, consider adding guidance for cases where the buggy function has multiple callers that persist its output to different tables/columns (or both ingestion-time and update-time writes) so the workflow is clear about how to prioritize or handle multiple persistence boundaries.
- In the data migration section of Step 5, it may help to specify what to do when a repo has more than one migration style (e.g., raw SQL and ORM helpers) so the implementer knows which convention to follow when creating the new migration.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[github-actions]

Eval Results

Eval Results: triage-bug

Eval	Passed	Failed	Pass Rate
eval-1	9/9	0	100%
eval-2	4/4	0	100%
eval-3	5/5	0	100%
eval-4	6/6	0	100%
eval-5	4/4	0	100%
eval-6	4/4	0	100%
eval-7	6/6	0	100%

Pass rate: 100% · Tokens: 37,631 · Duration: 141s

---

Generated by sdlc-workflow/run-evals v0.13.7

[mrizzi]

[sdlc-workflow/verify-pr] Re: @sourcery-ai review — 2 items classified:

1. "consider adding guidance for cases where the buggy function has multiple callers..." — Classified as suggestion — this proposes an optional enhancement for multi-persistence-boundary handling. No documented convention or established codebase pattern mandates multi-match disambiguation clauses in SKILL.md steps. No sub-task created.

2. "it may help to specify what to do when a repo has more than one migration style..." — Classified as suggestion — this proposes an optional enhancement for multi-migration-style handling. No documented convention requires this guidance. No sub-task created.

[mrizzi]

Verification Report for TC-5363 (commit 0b9c430)

Check	Result	Details
Review Feedback	PASS	2 suggestions from sourcery-ai; no code change requests
Root-Cause Investigation	N/A	No sub-tasks created
Scope Containment	WARN	All task files present; 3 extra eval files (evals.json, 2 mock fixtures)
Diff Size	PASS	231 additions across 4 files — proportionate for skill enhancement + eval coverage
Commit Traceability	PASS	Single commit references "Implements TC-5363" with required trailers
Sensitive Patterns	PASS	No secrets or credentials in added lines
CI Status	PASS	All 5 checks passed (Eval PR Run, Plugin Validation, Skill Lint, Sourcery, Trigger Eval Dispatch)
Acceptance Criteria	PASS	3 of 3 criteria met
Test Quality	PASS	Eval Quality: PASS (100% — 38/38 assertions across 7 evals); Repetitive Test Detection: N/A; Test Documentation: N/A
Test Change Classification	N/A	No traditional test files in PR
Verification Commands	N/A	No verification commands specified

Overall: WARN

Scope Containment is WARN due to 3 eval files not listed in the task's Files to Modify/Create. These are directly related to the feature (eval coverage for the new persistence-impact analysis) and were added at the user's request during implementation. No action required.

---

This comment was AI-generated by sdlc-workflow/verify-pr v0.13.7.