RepoImmune은 저장소의 해결된 버그를 코드 네이티브하고 증거 기반의 검증으로 변환하여, 인간과 코딩 에이전트가 조회할 수 있게 합니다.
입력 | 처리 | 출력 |
GitHub 저장소 또는 PR diff | 과거 이슈 → 수정 → 테스트 → AST 증거 검색 | 정확한 회귀 위치, 소스 링크, 보호 테스트, 과거 수정 내역 |
git clone https://github.com/Alex0AI/RepoImmune.git
cd RepoImmune
python -m venv .venv
# Windows: .venv\Scripts\activate
# macOS/Linux: source .venv/bin/activate
python -m pip install -e .
repoimmune init .
repoimmune check --diff examples/reintroduce-astropy-12907.diff --memory examples/memory
repoimmune replay astropy-12907 --memory examples/memory
repoimmune report --format html데모는 오프라인에서 실행되며, 런타임에 키나 의존성이 필요 없습니다. 이 검사는 Astropy PR #12907에서 실제 과거 회귀를 발견하기 때문에 의도적으로 종료 코드 2를 반환합니다.
Related MCP server: mcp-software-engineering-challenge
flowchart LR
I[Issue / report] --> B[Buggy commit]
B --> F[Failing behavior]
F --> P[Fix PR / commit]
P --> T[Regression test]
T --> S[AST + symbol change]
S --> V[Repository invariant]
V --> C[Patch immunity check]Behavior Card는 채팅 요약이 아닙니다. 수정 전/후 코드, AST 형태, 정확한 심볼, 회귀 테스트, 커밋, 소스 URL, 라이선스, 증거 클래스, 그리고 선택적 재생 캡슐에 불변 조건을 바인딩합니다.
- cright[-right.shape[0]:, -right.shape[1]:] = right
+ cright[-right.shape[0]:, -right.shape[1]:] = 1정확한 줄을 보고하고, 해당 코드 블록이 과거에 왜 잘못되었는지 설명하며, 이슈/PR/병합 커밋을 연결하고, 해당 수정 사항과 함께 추가된 pytest 케이스를 명시합니다.
repoimmune init .
repoimmune mine --repo owner/project
repoimmune check --diff HEAD~1
repoimmune recall "pagination returns duplicate rows"
repoimmune explain <behavior-card-id>
repoimmune replay <capsule-id>
repoimmune report --format html
repoimmune validate <card.json>check는 Markdown, JSON 또는 SARIF를 출력합니다. mine은 보수적인 후보만 저장하며, LLM을 호출하지 않고 제목만으로 Behavior Card를 주장하지 않습니다.
복합 GitHub Action은 풀 리퀘스트 diff를 읽기 전용으로 분석하고 SARIF/Markdown 증거를 업로드합니다.
stdio MCP 서버는 6개의 구조화된 읽기 전용 도구를 제공합니다: search_past_failures, explain_code_history, check_patch_against_memory, list_invariants_for_file, get_regression_test, replay_behavior_case.
공개 Agent Skill은 에이전트가 위험한 편집 전에 과거 기록을 회상하고, 완료를 주장하기 전에 다시 확인하도록 요청합니다. 커밋, 푸시, 병합 또는 테스트 우회 권한은 부여하지 않습니다.
정적 데모는 로그인이나 API 키 없이 동작합니다.
모든 결과는 명시적으로 다음 중 하나입니다:
verified: 기본 코드/테스트 증거로 직접 재생되거나 기계적으로 확인됨.
externally_reported: 신뢰할 수 있는 업스트림 또는 벤치마크 기록에서 가져왔으며, 여기서 재생산되지 않음.
heuristic: 유용한 후보 또는 유사성 신호이며, 증명이 아님.
inconclusive: 상충되거나 불완전한 증거.
유사성 점수는 결코 증명으로 제시되지 않습니다. 발견 사항은 항상 일치하는 소스와 증거를 함께 표시합니다.
에이전트/채팅 메모리: 대화 내용이나 저장소 사실을 기억합니다; RepoImmune은 코드 기록을 마이닝하여 모든 에이전트 세션보다 오래 지속되는 기계적 검증을 생성합니다.
SWE-bench: 에이전트가 이슈를 수리할 수 있는지 평가합니다; RepoImmune은 해결된 이슈를 지속적인 방지 자산으로 변환합니다.
정적 분석: 일반 규칙에서 시작합니다; RepoImmune은 해당 저장소의 실제 실패에서 저장소 특화 불변 조건을 학습합니다.
테스트 생성: 테스트를 생성할 수 있습니다; RepoImmune은 보고서, 버그가 있는 코드, 수정된 코드, 테스트, 불변 조건 간의 인과 사슬을 보존합니다.
git blame: 누가와 언제를 알려줍니다; RepoImmune은 왜 동작이 유지되어야 하는지 설명하고 이를 검증할 수 있습니다.
자세한 증거 기반 비교는 research-landscape.md를 참조하세요.
이슈 본문, PR 댓글, 코드, 패치 및 저장소 메타데이터는 신뢰할 수 없는 데이터입니다. RepoImmune은 이를 명령어로 평가하지 않습니다. 마이닝은 HTTPS 응답만 사용하며, refs와 저장소 이름은 검증됩니다. 캡슐 실행은 고정된 argv를 사용하고, 셸 없이 실행되며, 절대 경로와 심볼릭 링크를 거부하고, 시간 제한이 적용됩니다. 알 수 없는 저장소의 설치 스크립트나 테스트는 기본적으로 실행되지 않습니다. 자세한 내용은 SECURITY.md 및 docs/threat-model.md를 참조하세요.
알파 버전은 Python AST와 pytest 증거를 깊이 지원합니다. TypeScript/TSX는 선택적 고정(tree-sitter) 어댑터를 통해 정규화된 구조와 호출 추출을 제공합니다; JavaScript는 결정적 토큰 구조를 사용하며, Jest/Vitest는 테스트 증거로 기록될 수 있습니다. 프로그램 전체의 절차 간 도달 가능성 분석, 자동 업스트림 환경 재구성, 광범위한 언어 지원은 로드맵 항목입니다. 데이터셋 규모의 카드는 재생될 때까지 externally_reported로 표시됩니다; 번들된 Astropy 수직 슬라이스만이 v0.1.0에서 로컬로 검증된 동작 캡슐입니다.
python scripts/build_research_snapshot.py --limit 500 --cards 120
python scripts/run_experiments.py
pytest
coverage run -m pytest && coverage report
ruff check . && mypy src/repoimmune모든 게시된 수치는 research/results.json에서 재생성됩니다; 분류와 한계는 실패하거나 불확실한 경우를 포함하여 보존됩니다. 데이터 출처는 DATA_SOURCES.md, THIRD_PARTY.md, research/data-card.md에 명시되어 있습니다.
커밋된 v0.1 스냅샷에는 500개의 후보, 120개의 Behavior Card, 12개의 저장소, 30개의 경량 구조 캡슐이 포함되어 있습니다. 결정적 변형에 대해 120/120개의 정확한 과거 회귀를 탐지했고, 120/120개의 보호된 단언 삭제를 탐지했습니다; 동일 심볼 고정 형태 리팩터링에서는 9/120개의 오탐지(7.5%)가 발생했습니다. 제목 기반 검색은 Recall@5/MRR 1.0/1.0을 달성했지만, 이는 명시적으로 동일 소스 파이프라인 테스트입니다. 독립적인 마이닝 정밀도와 통제된 Agent A/B 평가는 아직 결론이 나지 않았습니다.
새로운 마이너 또는 증거 소스를 제안하기 전에 CONTRIBUTING.md, 로드맵 및 Behavior Card 스키마를 읽어보세요. Apache 2.0 라이선스입니다.
중국어 설명: README.zh-CN.md
check patch against memory
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only restates the tool name and gives no indication of side effects, return behavior, input expectations, or what 'memory' refers to.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal but not meaningfully concise; it is under-specified. It provides no front-loaded useful content and reads as a placeholder rather than a structured tool definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters and no output schema, the tool still needs context such as what 'patch' and 'memory' refer to and what the result indicates. The description is completely inadequate for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. There is no parameter information missing or requiring compensation from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'check patch against memory' is a verbatim restatement of the tool name, providing no additional information about what the tool actually does. It is a tautology that fails to distinguish itself from the sibling tools such as search_past_failures or explain_code_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance whatsoever about when to use this tool versus alternatives. The description offers no context, prerequisites, or exclusions, leaving an agent to guess when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain code history
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description adds zero behavioral information. It does not disclose whether this is a read-only operation, how it retrieves history, what output format to expect, or any side effects. The description carries the full burden for behavioral disclosure and fails entirely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, but brevity here is under-specification rather than efficient conciseness. A single phrase that repeats the tool name without elaboration does not earn credit for structure; it fails to convey any substantive information while appearing to be a complete definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and a descriptor that is a tautology. Given its sibling tools perform distinct historical/diagnostic functions, an agent cannot determine what inputs are needed, what results to expect, or how this differs from related operations. The definition is completely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts 0 parameters, so there is nothing for the description to clarify about argument meanings. Per the baseline for 0-parameter tools, this dimension is not penalized for missing parameter documentation. The description's lack of context does not affect this score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'explain code history' is essentially a restatement of the tool name with a verb and resource, but it provides no actual explanation of what 'explain' means in this context or what 'code history' refers to. It is a tautology, not a clear statement of function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus its siblings like search_past_failures or replay_behavior_case. No context, prerequisites, or situational cues are provided. The agent is left to guess which scenario would call for explaining code history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get regression test
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden, but it reveals nothing about behavior, side effects, return values, or error cases. It is purely a label, not a behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is extremely short, but this is under-specification rather than useful conciseness. It says nothing beyond the tool name and provides no structured or front-loaded information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is entirely inadequate. It does not explain what a regression test is, what the tool returns, or how it relates to the listed sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool declares zero parameters, so the baseline is 4; the description adds no parameter meaning, but there are no parameters for it to explain. The permissive additionalProperties: true schema is not clarified, but that is a minor gap with no required inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'get regression test' merely restates the tool name and adds no verb-resource detail beyond it. It does not distinguish this tool from siblings like search_past_failures or replay_behavior_case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool or when to prefer a sibling. No context, conditions, or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list invariants for file
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only repeats the action 'list' and the resource 'file'. It does not mention side effects (likely read-only), error conditions, ordering, filtering, or what data is actually returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence is concise, but this is under-specification rather than efficient brevity. The description omits essential details that an agent needs, so it does not earn credit for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must provide nearly all context. It fails to state how the file is selected, what invariants look like, or what a successful call returns, leaving the agent with only the tool name as guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero declared parameters, so the description cannot add parameter-level detail beyond the schema. The 100% schema coverage and empty parameter list make the missing specification less harmful, though the description does not explain how 'file' is supplied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'list invariants for file' is a near-verbatim restatement of the tool name. It identifies the action and resource but does not clarify what 'invariants' means in this context or how it differs from the sibling tools, making it tautological rather than informative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool instead of alternatives such as search_past_failures or check_patch_against_memory. There is no context, prerequisite, or exclusion information, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
replay behavior case
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to state side effects, permissions, return values, or any observable behavior beyond the vague verb 'replay'. There is nothing here to inform an agent about what will happen when the tool is invoked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three words is technically concise, but this is under-specification rather than effective structure. The description has no front-loaded action statement, no scoping, and no differentiation—it reads as a placeholder, not a deliberate, minimal definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, no parameter details, and only sibling tool names for context, the description is the sole source of guidance and it provides none. An agent cannot understand what a 'behavior case' is, what replaying entails, or what result to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description has no parameter details to explain, and the baseline is 4. However, the schema allows additionalProperties: true, meaning arbitrary input could be passed, and the description offers no hint about what properties might be relevant. This is a minor gap given no defined parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is literally the tool name: 'replay behavior case'. It restates the name without defining the action, the resource, or the domain meaning of 'behavior case'. An agent cannot distinguish it from siblings like search_past_failures or get_regression_test.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives, no context, and no examples. The description contains only a phrase with no actionable direction, so an agent receives zero assistance in selecting it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search past failures
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does not state whether this is a read-only query, what data it covers, what it returns, or any side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but not appropriately concise; it is under-specified. It consists only of a tautological phrase that adds no actionable information for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and no usage guidance, the description is completely inadequate for an agent to decide when to invoke this tool or what behavior to expect. The tool cannot be used correctly based on the provided definition alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters for the agent to interprethysics, which matches the baseline of 4. No parameter documentation is necessary since the input schema is effectively unrestricted and empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'search past failures' merely restates the tool name, providing no meaningful elaboration on what constitutes a 'past failure' or what the search returns. It also offers no differentiation from sibling tools like get_regression_test or replay_behavior_case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus the sibling alternatives. There is no mention of intended scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0check_patch_against_memoryexplain_code_historyget_regression_testlist_invariants_for_filereplay_behavior_casesearch_past_failuresScored across 6 tools
Each tool targets a distinct action and resource, but some functional overlap exists: 'search_past_failures' and 'get_regression_test' both relate to historical failures, and 'explain_code_history' and 'check_patch_against_memory' both deal with stored repository memory. The descriptions are terse but generally enough to guide selection.
All tool names follow a consistent lowercase snake_case verb-first pattern: search_, explain_, check_, list_, get_, replay_. The naming style is uniform and predictable across the entire set.
Six tools is well-scoped for a specialized repository memory/invariant server. Each tool has a clear purpose, and the count feels neither thin nor bloated for the apparent domain.
The surface covers the main read/replay workflow: searching failures, explaining history, checking patches, listing invariants, and replaying test cases. The only notable gap is the lack of any tool to record or update memory/invariants, but this may be intentional if ingestion happens outside the server.
A read-only verified record of agent-operable GTM tools: search, fetch, compare, track changes.
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Read-only AI coding tools for change verification, release readiness, capacity, and guidance.
Never let your agent repeat a bug or linger on a known issue. Search 385+ failure lessons to skip known errors instantly.
