Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Support revision-bound finding and hotspot evidence for bounded code-analysis tasks

Open
  • Is something wrong?
#55 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 9 days

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
tooling

Research direction

Start by reading related issues #34, #47 and #54 to understand the planned artifact and work-scope contracts. Define a versioned finding input and deterministic consumer projection with explicit validation, policy, correlation and bounded-slice behavior; the issue does not name implementation files or tests. Done means the listed offline fixtures, stable candidate IDs, explainable evidence and profile documentation are covered without adding a Vital or feeding findings into Integrity.

Written by the indexing model from the issue text.

Description

Problem

Repository activity and aggregate Vitals cannot identify which file, symbol or integration boundary should be analyzed. The Coverage and TestState Instruments planned in #34/#47 provide useful evidence, but do not define a source-location finding inventory or a reproducible rule for producing a bounded code-analysis task.

Without that surface, consumers either ask a model to inspect the whole project or turn weak heuristics such as file size into unsupported bug claims.

Proposed scope

Define an optional versioned finding/artifact input and a deterministic consumer projection, separable from the seven Vitals. A companion adapter is acceptable if source analysis is outside the core.

  • Accept existing CI reports: static/security findings with rule IDs and source locations (e.g. a declared SARIF profile), test failures/flakes, coverage gaps, and measured performance regressions. Git churn, complexity and changed dependency boundaries can be optional declared profiles.
  • Bind each artifact to repository identity, exact commit, producer/profile version, content digest, collection time and completeness. Validate paths/locations; artifacts from another revision are not current findings.
  • Make missing instrumentation UNKNOWN/UNAVAILABLE; it is never zero findings or complete coverage.
  • Define policy predicates such as "recently changed code with missing applicable test reach", "repeated failed test at a named boundary", or "complexity plus observed churn". Thresholds and windows are explicit consumer policy. A predicate produces an analysis candidate, not a proven defect or an invented business priority.
  • Include named paths/symbols, rule and evidence refs, the observed risk/question, a bounded read set and a concrete expected verification result. Prefer component-local slices over repository-wide prompts.
  • Correlate a finding with existing issues/MRs and retained dispositions so identical runs do not reopen accepted findings or produce duplicate tasks. A changed revision, new evidence or expired disposition can require reconsideration.

Do not use raw source/report text as authority, execute producer-supplied commands, or treat a large file alone as a bug. Do not add an eighth Vital or feed these findings into Integrity without a separately accepted contract.

Acceptance

  • Offline fixtures cover absent, malformed, truncated, duplicate and stale reports; wrong repository/revision; out-of-tree paths; unavailable coverage; acknowledged findings; a new recurrence; overlap with an existing MR.
  • Same artifacts and policy yield the same candidates and stable IDs.
  • A candidate can be explained from named evidence without a model.
  • Generated slices include path/symbol, observed trigger, review objective and bounded context; unknown input never fabricates "all clear".
  • Document at least one static-finding and one test/coverage profile, their limits, and how a consumer maps them into analyze_code or a declared research question.

Related: #34 and #47. This extends their artifact evidence into actionable source slices; it does not duplicate the planned Coverage/TestState Instruments.

Work-scope projection proposal: https://github.com/drevendev/Devostasis/issues/54

Dominant language
Python
Stars
4
Forks
1
Avg merge
5d 12h
Merged PRs (30d)
3

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from drevendev/Devostasis

All issues in drevendev/Devostasis

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.