Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

FEAT Add role-aware Scenario target-attempt accounting

オープン
  • 何か問題がありますか？
#3,043 コメント 3 件 リアクション 0 件 担当者 1 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

@Nimit3418 がすでに取り組んでいます。

2026年10月9日 から。

  • #3062 @Nimit3418 による — オープン

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
azure, python, sqlite
領域
backend, data, databases

調査の方向性

Start with pyrit/analytics/scenario_statistics.py, pyrit/backend/services/scenario_progress_read_model.py, and pyrit/memory/memory_interface.py, plus the AttackResultMetadata contract and doc/code/framework.md. Trace how shared analytics policy reaches memory aggregation and backend/SDK/report consumers; the issue also calls for SQLite runtime and Azure SQL compilation parity checks. Done means adding role-aware target-facing counts while preserving existing logical-progress and raw-history semantics, with the listed edge cases covered.

索引モデルが issue の本文から書いたものです。

説明

feature-request help wanted
Is your feature request related to a problem? Please describe.

Current main records producer roles but does not use them for target-attempt
rollups. The shared analytics helper, progress, and history SQL count attempts
without a producer-role predicate. Thus their existing
logical-unit/raw-history counts must not be presented as target-attempt counts.

For example, two target-facing child results plus one Sequential envelope
are three historical result rows, but only two target-facing producer attempts.
The envelope can still complete one outer planned logical unit. A preparation
error may also have a target-facing role, so this role alone does not prove a
target request occurred. This check inspected code; it did not run an attack.

Describe the solution you'd like

Add a consumed typed target-facing accounting projection using the existing
AttackResultMetadata contract and shared Scenario analytics/identity policy.
Keep planned logical progress, raw historical attempts, and target-facing
attempts distinct. Memory owns database aggregation; backend/SDK/report
consumers present the shared policy rather than independently infer roles.

Acceptance criteria:

  • Orchestration envelopes remain observable but contribute zero to target-facing
    attempts and their target-facing error/retry totals.
  • Preserve exact saved-plan denominators, outer-unit completion, existing
    latest-attempt identity/order, raw history, and #2551/#2820 cache inclusion.
    Add the new rollup without silently redefining existing unit/raw fields.
  • Legacy/malformed roles remain explicitly unknown using conservative decoding;
    never infer a role from a conversation ID, class name, display text, or index.
    Keep orchestration and unknown-role totals visible alongside target-facing
    totals so the producer categories reconcile with raw history.
  • Report unmatched attempts separately, with the same matching policy across
    progress, detail, SDK/report consumers, and history.
  • Real-domain/SQLite parity cases cover ordinary/baseline, flat and nested
    Sequential/Adaptive, retry/resume, recovered and unrecovered errors,
    preparation failure, negative retries, unknown roles, invalid plans,
    tied timestamps, and cache hits.
  • SQLite runtime and Azure SQL compilation cover equivalent database-side
    role filtering. Do not add full-result hydration, per-attempt queries, or
    Python grouping as a replacement for the new SQL aggregate.
  • Field names and documentation say target-facing producer attempts, not
    confirmed target invocations; no new request-tracing feature is required.

Dependencies: merged #2997 and #2820; coordinate indexed analytics #2792 and
history-query extractions #2768/#2769. The separate child-link fix #3039 and
dataset/technique UX are not hard dependencies for counting persisted roles.

Describe alternatives you've considered, if relevant

Do not redo shared success statistics, change logical completion to child
counts, or remove historical rows. Exclude schema/duplicate hierarchy stores,
child-link repair, hierarchy endpoints/UI, dataset/estimate changes, request
tracing, scorer semantics, and new attack algorithms.

Additional context

Roadmap: scope 8.
Design: original result/accounting references.
Evidence: upstream 58a93534838ed58e766276c060c4f0d9149d6483,
pyrit/analytics/scenario_statistics.py,
pyrit/backend/services/scenario_progress_read_model.py, and
pyrit/memory/memory_interface.py.
Follow doc/code/framework.md: models own types, analytics owns counting
policy, memory persists/aggregates, and backend/output present it.
No GUI change or unrelated screenshots are requested.

主要言語
Python
スター
4.6k
フォーク
924
平均マージ
3日 4時間
マージ済み PR（30日）
264

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

  • Dockerfile・Docker Compose ファイルなし
  • プルリクエストのテンプレートあり
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

microsoft/PyRIT のほかの issue

microsoft/PyRIT の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。