[BLOCKED] FEAT: Drill into paired Scenario outcome conversations
I maintainer di solito rispondono entro 2 giorni
@shashank03-dev ci sta già lavorando.
Dal 20/10/2026.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 10/100
Direzione di ricerca
The issue places this work on the Scenario run results page and says to reuse backend pairing semantics and existing conversation routes. First inspect the implementation from PR #3337 and the open follow-up PR #3391, then check whether the stated ownership block has been cleared. Done means transition rows can load and collapse matching pairs on demand, with bounded loading, accessible navigation, and clear loading, empty, and retryable error states.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Is your feature request related to a problem? Please describe.
The Paired outcomes panel on a Scenario run reports transitions such as one baseline failure becoming an attack success, but there is no way to inspect which objective and conversations produced that transition. Aggregate counts alone make it difficult to investigate the differences.
Describe the solution you'd like
BLOCKED pending @shashank03-dev's decision. He may want to pick this up as the author of #3337. Please do not start implementation or claim the work until he decides whether he wants to take it. If he opts in, coordinate ownership with him; if he declines, this can be opened to other contributors. The help wanted label does not override this block.
On the Scenario run results page:
- Make each paired-outcome transition row expandable on demand and collapsible again.
- Expanding a row should load the matching baseline/attack pairs, rather than eagerly loading all conversations with the initial comparison.
- Show the objective or logical seed and useful context for both sides of each pair, including their outcomes. Provide clear navigation to the relevant baseline and attack conversations using the existing conversation routes and Scenario context.
- Keep the selected groups, latest top-level attempt rules, and decided-pair population consistent with the displayed transition count. Reuse backend pairing semantics rather than calculating a separate cohort in the GUI.
- Support bounded loading or pagination for large categories, keyboard-accessible expansion/navigation, and clear loading, empty, and retryable error states. Users must be able to collapse an expanded category again.
For example, expanding Failure -> Success: 1 should reveal the matching pair and let the user inspect the baseline conversation and the successful attack conversation.
Describe alternatives you've considered, if relevant
Keeping aggregate counts only requires users to locate matching results manually. A single conversation link on a category would not work when it contains multiple pairs. Loading every conversation with the initial comparison would add unnecessary work for large Scenario runs. On-demand row expansion lets users investigate the transition they care about without that upfront cost.
Additional context
Follow-up to merged PR #3337. This belongs to Scenario run results, not general attack-result analytics: the saved run plan identifies the baseline, attack groups, and matched seed population.
This issue is coordination-blocked pending @shashank03-dev deciding either way; no follow-up implementation should start until that block is cleared.
- Lingua principale
- Python
- Stelle
- 4.7k
- Fork
- 980
- Merge medio
- 2g 13h
- PR unite (30g)
- 407
Preparare l'ambiente
Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Nessuna guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di microsoft/PyRIT
-
BUG: AzureBlobStorageTarget returns a URL with // when the container URL ends with a slashForse già presa @ShivamSharma43 l’ha presa 2 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 2 giorni
-
BUG: XXEOutputScorer misses direct external DTD references and Java netdoc: / gopher: URI schemesForse già presa @Kaap10 l’ha presa 2 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 2 giorni
-
BUG: MarkdownInjectionScorer misses shortcut-reference images with path-based exfiltration, and raw HTML <img>Forse già presa @aatif101 l’ha presa 6 giorni fa. ApertaBug: triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
microsoft/PyRIT#3343 · 2 commenti · 1 assegnatario ·
I maintainer di solito rispondono entro 2 giorni
-
BUG BrailleConverter output is ambiguous: "1a" encodes the same as "11", and "$" uses the period cellForse già presa @barkha1research-ai l’ha presa oggi. ApertaBug: triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 25/100
I maintainer di solito rispondono entro 2 giorni
-
BUG: Inferred objective is empty when tool calls come between the request and the answerForse già presa @Shizoqua l’ha presa 1 giorno fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 25/100
I maintainer di solito rispondono entro 2 giorni
Tutte le issue di microsoft/PyRIT
Issue simili
-
The changelog workflow excludes otelbot but not dependabot, so every Dependabot pull request fails the changelog checkForse già presa @ocelotl l’ha presa oggi. Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 82/100
open-telemetry/opentelemetry-python#5825 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
cuga-project/cuga-agent#1020 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 70/100
microsoft/playwright#43640 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
stac-utils/stac-fastapi-elasticsearch-opensearch#965 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
I maintainer di solito rispondono entro 1 giorno