⚡ Bolt: [성능 개선] label_section에서 정규표현식 재컴파일 제거

[seonghobae]

💡 What: scripts/ci/opencode_review_normalize_output.py 파일의 label_starts 함수 내에 존재하던 정규식 런타임 컴파일 중복 방지 코드를 추가했습니다.
🎯 Why: 기존 코드는 반복적으로 호출되는 label_starts 함수에서 APPROVAL_VERIFICATION_PATTERNS에 키가 없을 경우 매번 re.compile(re.escape(candidate))를 호출했습니다. 하지만 이 호출의 결과를 딕셔너리에 저장하지 않아, 동일한 라벨이 계속 등장하는 경우 매번 정규식을 다시 컴파일하는 불필요한 성능 비용(O(N))을 초래했습니다.
📊 Impact: 라벨 검증 및 텍스트 파싱 과정에서 발생하는 반복적인 런타임 정규식(Regex) 재컴파일 오버헤드를 O(1) 수준으로 감소시켜, 리뷰 크기가 클수록 더욱 효과적으로 성능을 개선합니다.
🔬 Measurement: interrogate -c pyproject.toml -v 및 mypy --explicit-package-bases scripts/ci로 변경 사항으로 인해 파괴적인 변경이 발생하지 않는지 확인했으며, pytest tests/test_opencode_review_normalize_output.py로 관련 유닛 테스트가 통과하는지 검증했습니다.

---

PR created automatically by Jules for task 3535098232947521793 started by @seonghobae

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[coderabbitai]

Warning

Review limit reached

@seonghobae, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 1 minute

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 29c61c66-7883-4057-ac79-b1c2d5500754

📥 Commits

Reviewing files that changed from the base of the PR and between f070c50 and 57589ba.

📒 Files selected for processing (2)

• .jules/bolt.md
• scripts/ci/opencode_review_normalize_output.py

---

_{Comment @coderabbitai help to get the list of available commands.}

[opencode-agent]

OpenCode Review Overview

• Head SHA: 57589ba1414112b17d503d83d0fc11c5bf276618
• Workflow run: 31110471077
• Workflow attempt: 1
• Gate result: REQUEST_CHANGES (approval step)

Pull request overview

OpenCode reviewed the current-head bounded evidence and requested changes before merge.

Findings

1. P2 .jules/bolt.md:46 - Learning entry names a non-existent label_matches inner function, contradicting the changed code

• Problem: The new learning entry (lines 46-48) states the regex-recompilation anti-pattern was found inside the label_matches inner function of scripts/ci/opencode_review_normalize_output.py. Current-head code defines the inner function as label_starts (focused hunk def label_starts(candidate: str)), and no label_matches symbol appears in the changed files, so the changed documentation contradicts the code it describes; the entry also asserts measurable overhead without any benchmark evidence.
• Root cause: The learning note was written from an approximate or stale function reference instead of the actual current-head symbol label_starts.
• Fix: Rename label_matches to label_starts in the Learning: sentence (and either attach the measured-overhead benchmark or soften the claim). Suggested diff below.
• Regression test: python3 -m pytest tests, plus grep -rn 'label_matches' scripts/ci/opencode_review_normalize_output.py .jules/bolt.md should return no matches after the fix.
• Suggested diff: posted in this finding's inline review thread.

Summary

Changed-file evidence inspected: .jules/bolt.md (new learning entry, lines 46-48) and scripts/ci/opencode_review_normalize_output.py (regex memoization at line 892). The code change itself is behavior-preserving (deterministic re.escape cache), but the learning note names a non-existent label_matches inner function, contradicting the changed label_starts function. Approval sufficiency: REQUEST_CHANGES on a source-backed docs-to-code contradiction. Verification posture: trusted Coverage execution evidence reports Result PASS - supported repository test suites passed (python3 -m pytest tests). Linter/static: no linter evidence collected; source-trace review only. TDD/regression: no new test for the label_section cache; repository suite passed. Coverage: Coverage execution evidence Result PASS for head 57589ba. Docstring coverage: configured docstring gates passed or advisory per Coverage execution evidence. DAG: Mermaid flowchart in prose maps label_section -> label_starts -> APPROVAL_VERIFICATION_PATTERNS cache write (line 892) at head. PoC/execution: no execution receipts beyond trusted coverage evidence; direct pr-head source reads were denied, so analysis relied on focused current-head hunks and CodeGraph. DDD/domain: CI review-normalization script; no domain model impact. CDD/context: one changed script plus learning journal; no context boundaries crossed. Similar issues: sibling Bolt PRs #481/#465/#557 memoize I/O and subprocess reads; this PR caches into the existing module dict. Claim/concept check: the note's label_matches reference fails against current code. Standards search: no external standard implicated; regex memoization is idiomatic Python. Compatibility/convention: no new public identifiers; APPROVAL_VERIFICATION_PATTERNS[candidate] write mutates an existing module-level dict (residual risk noted). Breaking-change/backcompat: none; behavior preserved. Implementation completeness: change is complete and functional. Performance: memoized compile reduces repeated regex compilation in label loops. Developer experience: CI review-script surface; learning-journal entry should name the real function. User experience: non-web CI script surface; no UI impact. Visual/DOM: non-web; CLI/log surface reviewed instead. Accessibility/i18n: not applicable to this CI script change. Supply-chain/license: no dependency changes. Packaging: no packaging changes. Security/privacy: no auth, secrets, or identifier-exposure surfaces changed.

Adversarial validation

{"status":"failed","probes":[{"path":".jules/bolt.md","line":46,"hypothesis":"The new learning entry added at .jules/bolt.md:46-48 claims the regex-recompilation anti-pattern was found inside a `label_matches` inner function of scripts/ci/opencode_review_normalize_output.py, i.e., the changed documentation names a code symbol that exists in current head.","attack_or_counterexample":"Cross-check the doc claim against the current-head changed code: does the normalize script define an inner function named label_matches, or is the changed inner function named label_starts?","evidence":"Trusted current-head focused hunk for scripts/ci/opencode_review_normalize_output.py shows the changed inner function is defined as `def label_starts(candidate: str) -> list[int]:` (hunk @@ -880,24 +880,25 @@) and the changed-files evidence contains no label_matches symbol, while the new .jules/bolt.md entry (header at line 46, Learning sentence immediately following) attributes the anti-pattern to the `label_matches` inner function; the documentation-to-code contradiction is confirmed at path:line .jules/bolt.md:46; source-line-sha256=e4feda6ecab265c4dc79ebd7576cdfaa611c3008ea48beae24f7f6ffff184989","outcome":"confirmed"},{"path":"scripts/ci/opencode_review_normalize_output.py","line":892,"hypothesis":"Caching the compiled re.escape(candidate) pattern into APPROVAL_VERIFICATION_PATTERNS changes the label-start offsets returned by label_starts on repeated calls (behavior change or cross-text contamination).","attack_or_counterexample":"Call label_starts twice with the same candidate and different texts and compare match offsets to the previously recompiled-per-call behavior.","evidence":"Source trace: re.escape(candidate) is a pure deterministic function of candidate, so the pattern stored at line 892 is byte-identical to the pattern previously recompiled on every miss; pattern.finditer(text) is therefore unchanged and cached lookups return identical offsets; trusted Coverage execution evidence for head 57589ba1 reports Result PASS with supported repository test suites passed, falsifying the behavior-change hypothesis at path:line scripts/ci/opencode_review_normalize_output.py:892; source-line-sha256=347fa7be77dcb2e1b70745b88011f9ea230eb4682a68a6fc0fa5fe34207b183e","outcome":"falsified"}],"residual_risk":"The cache write mutates the shared module-level APPROVAL_VERIFICATION_PATTERNS dict; other consumers of that dict could not be inspected because direct source reads of the pr-head tree were denied (source limitation). If any code path iterates the dict to enumerate known verification labels, dynamically cached keys could broaden label detection. Recommend a focused unit test asserting label_section/label_starts output is unchanged before and after repeated calls."}

• Result: REQUEST_CHANGES

• Reason: The new .jules/bolt.md learning entry attributes the regex-recompilation anti-pattern to a label_matches inner function that does not exist in current-head code; the changed inner function is label_starts, a source-backed documentation-to-code contradiction that must be fixed per the repository review contract.

• Head SHA: 57589ba1414112b17d503d83d0fc11c5bf276618

• Workflow run: 31110471077

• Workflow attempt: 1

Changed-File Evidence Map

flowchart LR
  PR["PR changed files"] --> Evidence["OpenCode bounded evidence"]
  Evidence --> S1["Changed file: bolt.md"]
  S1 --> I1["repository behavior"]
  I1 --> R1["Review risk: Changed file: bolt.md"]
  R1 --> V1["required checks"]
  Evidence --> S2["CI script: opencode_review_normalize_output.py"]
  S2 --> I2["review and security gate shell path"]
  I2 --> R2["Review risk: CI script: opencode_review_normalize_output.py"]
  R2 --> V2["bash -n plus Strix self-test"]

Loading

[opencode-agent]

Pull request overview

OpenCode reviewed the current-head bounded evidence and requested changes before merge.

Findings

1. P2 .jules/bolt.md:46 - Learning entry names a non-existent label_matches inner function, contradicting the changed code

• Problem: The new learning entry (lines 46-48) states the regex-recompilation anti-pattern was found inside the label_matches inner function of scripts/ci/opencode_review_normalize_output.py. Current-head code defines the inner function as label_starts (focused hunk def label_starts(candidate: str)), and no label_matches symbol appears in the changed files, so the changed documentation contradicts the code it describes; the entry also asserts measurable overhead without any benchmark evidence.
• Root cause: The learning note was written from an approximate or stale function reference instead of the actual current-head symbol label_starts.
• Fix: Rename label_matches to label_starts in the Learning: sentence (and either attach the measured-overhead benchmark or soften the claim). Suggested diff below.
• Regression test: python3 -m pytest tests, plus grep -rn 'label_matches' scripts/ci/opencode_review_normalize_output.py .jules/bolt.md should return no matches after the fix.
• Suggested diff: posted in this finding's inline review thread.

Summary

Changed-file evidence inspected: .jules/bolt.md (new learning entry, lines 46-48) and scripts/ci/opencode_review_normalize_output.py (regex memoization at line 892). The code change itself is behavior-preserving (deterministic re.escape cache), but the learning note names a non-existent label_matches inner function, contradicting the changed label_starts function. Approval sufficiency: REQUEST_CHANGES on a source-backed docs-to-code contradiction. Verification posture: trusted Coverage execution evidence reports Result PASS - supported repository test suites passed (python3 -m pytest tests). Linter/static: no linter evidence collected; source-trace review only. TDD/regression: no new test for the label_section cache; repository suite passed. Coverage: Coverage execution evidence Result PASS for head 57589ba. Docstring coverage: configured docstring gates passed or advisory per Coverage execution evidence. DAG: Mermaid flowchart in prose maps label_section -> label_starts -> APPROVAL_VERIFICATION_PATTERNS cache write (line 892) at head. PoC/execution: no execution receipts beyond trusted coverage evidence; direct pr-head source reads were denied, so analysis relied on focused current-head hunks and CodeGraph. DDD/domain: CI review-normalization script; no domain model impact. CDD/context: one changed script plus learning journal; no context boundaries crossed. Similar issues: sibling Bolt PRs #481/#465/#557 memoize I/O and subprocess reads; this PR caches into the existing module dict. Claim/concept check: the note's label_matches reference fails against current code. Standards search: no external standard implicated; regex memoization is idiomatic Python. Compatibility/convention: no new public identifiers; APPROVAL_VERIFICATION_PATTERNS[candidate] write mutates an existing module-level dict (residual risk noted). Breaking-change/backcompat: none; behavior preserved. Implementation completeness: change is complete and functional. Performance: memoized compile reduces repeated regex compilation in label loops. Developer experience: CI review-script surface; learning-journal entry should name the real function. User experience: non-web CI script surface; no UI impact. Visual/DOM: non-web; CLI/log surface reviewed instead. Accessibility/i18n: not applicable to this CI script change. Supply-chain/license: no dependency changes. Packaging: no packaging changes. Security/privacy: no auth, secrets, or identifier-exposure surfaces changed.

Adversarial validation

{"status":"failed","probes":[{"path":".jules/bolt.md","line":46,"hypothesis":"The new learning entry added at .jules/bolt.md:46-48 claims the regex-recompilation anti-pattern was found inside a `label_matches` inner function of scripts/ci/opencode_review_normalize_output.py, i.e., the changed documentation names a code symbol that exists in current head.","attack_or_counterexample":"Cross-check the doc claim against the current-head changed code: does the normalize script define an inner function named label_matches, or is the changed inner function named label_starts?","evidence":"Trusted current-head focused hunk for scripts/ci/opencode_review_normalize_output.py shows the changed inner function is defined as `def label_starts(candidate: str) -> list[int]:` (hunk @@ -880,24 +880,25 @@) and the changed-files evidence contains no label_matches symbol, while the new .jules/bolt.md entry (header at line 46, Learning sentence immediately following) attributes the anti-pattern to the `label_matches` inner function; the documentation-to-code contradiction is confirmed at path:line .jules/bolt.md:46; source-line-sha256=e4feda6ecab265c4dc79ebd7576cdfaa611c3008ea48beae24f7f6ffff184989","outcome":"confirmed"},{"path":"scripts/ci/opencode_review_normalize_output.py","line":892,"hypothesis":"Caching the compiled re.escape(candidate) pattern into APPROVAL_VERIFICATION_PATTERNS changes the label-start offsets returned by label_starts on repeated calls (behavior change or cross-text contamination).","attack_or_counterexample":"Call label_starts twice with the same candidate and different texts and compare match offsets to the previously recompiled-per-call behavior.","evidence":"Source trace: re.escape(candidate) is a pure deterministic function of candidate, so the pattern stored at line 892 is byte-identical to the pattern previously recompiled on every miss; pattern.finditer(text) is therefore unchanged and cached lookups return identical offsets; trusted Coverage execution evidence for head 57589ba1 reports Result PASS with supported repository test suites passed, falsifying the behavior-change hypothesis at path:line scripts/ci/opencode_review_normalize_output.py:892; source-line-sha256=347fa7be77dcb2e1b70745b88011f9ea230eb4682a68a6fc0fa5fe34207b183e","outcome":"falsified"}],"residual_risk":"The cache write mutates the shared module-level APPROVAL_VERIFICATION_PATTERNS dict; other consumers of that dict could not be inspected because direct source reads of the pr-head tree were denied (source limitation). If any code path iterates the dict to enumerate known verification labels, dynamically cached keys could broaden label detection. Recommend a focused unit test asserting label_section/label_starts output is unchanged before and after repeated calls."}

• Result: REQUEST_CHANGES

• Reason: The new .jules/bolt.md learning entry attributes the regex-recompilation anti-pattern to a label_matches inner function that does not exist in current-head code; the changed inner function is label_starts, a source-backed documentation-to-code contradiction that must be fixed per the repository review contract.

• Head SHA: 57589ba1414112b17d503d83d0fc11c5bf276618

• Workflow run: 31110471077

• Workflow attempt: 1

Changed-File Evidence Map

flowchart LR
  PR["PR changed files"] --> Evidence["OpenCode bounded evidence"]
  Evidence --> S1["Changed file: bolt.md"]
  S1 --> I1["repository behavior"]
  I1 --> R1["Review risk: Changed file: bolt.md"]
  R1 --> V1["required checks"]
  Evidence --> S2["CI script: opencode_review_normalize_output.py"]
  S2 --> I2["review and security gate shell path"]
  I2 --> R2["Review risk: CI script: opencode_review_normalize_output.py"]
  R2 --> V2["bash -n plus Strix self-test"]

Loading

[opencode-agent]

P2 Learning entry names a non-existent label_matches inner function, contradicting the changed code

• Location: .jules/bolt.md:46
• Problem: The new learning entry (lines 46-48) states the regex-recompilation anti-pattern was found inside the label_matches inner function of scripts/ci/opencode_review_normalize_output.py. Current-head code defines the inner function as label_starts (focused hunk def label_starts(candidate: str)), and no label_matches symbol appears in the changed files, so the changed documentation contradicts the code it describes; the entry also asserts measurable overhead without any benchmark evidence.
• Root cause: The learning note was written from an approximate or stale function reference instead of the actual current-head symbol label_starts.
• Fix: Rename label_matches to label_starts in the Learning: sentence (and either attach the measured-overhead benchmark or soften the claim). Suggested diff below.
• Regression test: python3 -m pytest tests, plus grep -rn 'label_matches' scripts/ci/opencode_review_normalize_output.py .jules/bolt.md should return no matches after the fix.

Suggested diff

--- a/.jules/bolt.md
+++ b/.jules/bolt.md
@@ -47 +47 @@
-**Learning:** Found a codebase-specific anti-pattern in `scripts/ci/opencode_review_normalize_output.py` where deep label-scanning loops over long review texts were redundantly recompiling regexes for verification labels inside the `label_matches` inner function. This caused measurable overhead in the CI review script.
+**Learning:** Found a codebase-specific anti-pattern in `scripts/ci/opencode_review_normalize_output.py` where deep label-scanning loops over long review texts were redundantly recompiling regexes for verification labels inside the `label_starts` inner function. This caused measurable overhead in the CI review script.