Walkthrough: a real pull request (leave open) #1

A-Guevara · 2026-08-27T23:44:12Z

A-Guevara commented

2026-08-27 23:44:12 +00:00

This PR exists for the guided tour: the AI review panel comments here, and the findings board appears under its review. Please leave it open.

This PR exists for the guided tour: the AI review panel comments here, and the findings board appears under its review. **Please leave it open.**

A-Guevara added 1 commit

2026-08-27 23:44:12 +00:00

tour: demo change for the walkthrough PR

hello / hello (push) Successful in 14s

Details

ai-review / review (pull_request) Successful in 1m8s

Details

55ac127355

ai-review-bot reviewed

2026-08-27 23:46:32 +00:00

ai-review-bot left a comment

AI review · advisory

Verdict: 3 things worth fixing (1 high · 1 medium · 1 low).

_{⚑ panel: GPT-OSS 120B · Gemma 4 31B · Devstral 2 123B · Laguna S 2.1 — 3 distinct (from 6 reviewer findings), 3 confirmed, 0 refuted · web: not used · context: 1 files · 0 codebase · 14 standards chunks}

Panel debate — how this review was reached

Grounding — context: 1 files · 0 codebase · 14 standards chunks

Round 1 — independent reviews

GPT-OSS 120B (1 finding, confidence 0.93): The added documentation file includes a date‑parsing snippet that should validate its input to avoid uncaught exceptions.
Gemma 4 31B (2 findings, confidence 1.0): The provided Python snippet is a deliberately naive implementation that lacks basic input validation, making it prone to ValueError crashes on malformed input.
Devstral 2 123B (2 findings, confidence 0.9): The date parsing function lacks input validation and error handling, which could lead to runtime errors.
Laguna S 2.1 (1 finding, confidence 0.9): The change introduces a documentation file with a deliberately naive date parser. No security-critical changes, dependency additions, or configuration modifications are present. The single low-severit

Grouping — 6 reviewer findings describe 3 distinct defects; reviewers who found the same defect independently count as support.

Round 2 — cross-examination

Devstral 2 123B#1 Unsafe date parsing without input validation · also raised by: GPT-OSS 120B, Gemma 4 31B, Laguna S 2.1 · confirmed: — · refuted: —
Devstral 2 123B#2 No handling of non-integer values in date components · confirmed: GPT-OSS 120B, Gemma 4 31B · refuted: —
Gemma 4 31B#2 Unchecked integer conversion can cause ValueError · confirmed: GPT-OSS 120B, Devstral 2 123B · refuted: —

Synthesis — Devstral 2 123B wrote the final review from 3 confirmed findings.

_{Transcript rv-20260827234555-d1be66 — full round outputs, web results, and model reasoning are viewable by anyone with access to this repository via the AI gateway.}

_{Advisory — never a merge gate. Disagree with a finding? Reply on it, or use the finding board under this review. Transcript rv-20260827234555-d1be66.}

### AI review · advisory  **Verdict: 3 things worth fixing** (1 high · 1 medium · 1 low). ⚑ panel: GPT-OSS 120B · Gemma 4 31B · Devstral 2 123B · Laguna S 2.1 — 3 distinct (from 6 reviewer findings), 3 confirmed, 0 refuted · web: not used · context: 1 files · 0 codebase · 14 standards chunks <details> <summary>Panel debate — how this review was reached</summary> **Grounding** — context: 1 files · 0 codebase · 14 standards chunks **Round 1 — independent reviews** - **GPT-OSS 120B** (1 finding, confidence 0.93): The added documentation file includes a date‑parsing snippet that should validate its input to avoid uncaught exceptions. - **Gemma 4 31B** (2 findings, confidence 1.0): The provided Python snippet is a deliberately naive implementation that lacks basic input validation, making it prone to ValueError crashes on malformed input. - **Devstral 2 123B** (2 findings, confidence 0.9): The date parsing function lacks input validation and error handling, which could lead to runtime errors. - **Laguna S 2.1** (1 finding, confidence 0.9): The change introduces a documentation file with a deliberately naive date parser. No security-critical changes, dependency additions, or configuration modifications are present. The single low-severit **Grouping** — 6 reviewer findings describe 3 distinct defects; reviewers who found the same defect independently count as support. **Round 2 — cross-examination** - `Devstral 2 123B#1` Unsafe date parsing without input validation · also raised by: GPT-OSS 120B, Gemma 4 31B, Laguna S 2.1 · confirmed: — · refuted: — - `Devstral 2 123B#2` No handling of non-integer values in date components · confirmed: GPT-OSS 120B, Gemma 4 31B · refuted: — - `Gemma 4 31B#2` Unchecked integer conversion can cause ValueError · confirmed: GPT-OSS 120B, Devstral 2 123B · refuted: — **Synthesis** — Devstral 2 123B wrote the final review from 3 confirmed findings. Transcript `rv-20260827234555-d1be66` — full round outputs, web results, and model reasoning are viewable by anyone with access to this repository via the AI gateway. </details> Advisory — never a merge gate. Disagree with a finding? Reply on it, or use the finding board under this review. Transcript `rv-20260827234555-d1be66`.

docs/demo.md

					
				@ -0,0 +4,4 @@

				The date parser below is deliberately naive — see what the AI panel says.

				```python

				def parse_date(s):

docs/demo.md:7 · HIGH — Unsafe date parsing without input validation
The parse_date function splits a string on hyphens and immediately converts the parts to integers, but it never checks whether the input is in the expected YYYY-MM-DD format. If a user passes a malformed string (e.g., 2024-1-1 or abc-def-ghi), the code will crash with a ValueError.

Fix: Wrap the entire parsing logic in a try-except block and validate that each component has the correct length (4, 2, 2) before converting to integers.

Proposed replacement (one-click ⚡ Apply on the findings board at the top of this PR):

def parse_date(s):
    try:
        y, m, d = s.split("-")
        if len(y) != 4 or len(m) != 2 or len(d) != 2:
            raise ValueError("Invalid date format")
        return int(y), int(m), int(d)
    except ValueError as e:
        raise ValueError(f"Invalid date format: {e}")

_{panel tally 4/4 · reply here or use the finding board to agree/disagree}

**`docs/demo.md:7`** · HIGH — Unsafe date parsing without input validation The `parse_date` function splits a string on hyphens and immediately converts the parts to integers, but it never checks whether the input is in the expected `YYYY-MM-DD` format. If a user passes a malformed string (e.g., `2024-1-1` or `abc-def-ghi`), the code will crash with a `ValueError`. > **Fix:** Wrap the entire parsing logic in a `try-except` block and validate that each component has the correct length (4, 2, 2) before converting to integers. **Proposed replacement** (one-click ⚡ Apply on the findings board at the top of this PR): ``` def parse_date(s): try: y, m, d = s.split("-") if len(y) != 4 or len(m) != 2 or len(d) != 2: raise ValueError("Invalid date format") return int(y), int(m), int(d) except ValueError as e: raise ValueError(f"Invalid date format: {e}") ``` panel tally 4/4 · reply here or use the finding board to agree/disagree

docs/demo.md

					
				@ -0,0 +5,4 @@

				```python

				def parse_date(s):

				    y, m, d = s.split("-")

docs/demo.md:8 · MEDIUM — No handling of non-integer values in date components
The function assumes the split parts of the string can always be converted to integers, but if any part contains letters or symbols (e.g., 2024-01-XX), int() will raise a ValueError and crash the program.

Fix: Add a try-except block around the int() conversions to catch and re-raise a clear error message.

_{panel tally 3/4 · reply here or use the finding board to agree/disagree}

**`docs/demo.md:8`** · MEDIUM — No handling of non-integer values in date components The function assumes the split parts of the string can always be converted to integers, but if any part contains letters or symbols (e.g., `2024-01-XX`), `int()` will raise a `ValueError` and crash the program. > **Fix:** Add a `try-except` block around the `int()` conversions to catch and re-raise a clear error message. panel tally 3/4 · reply here or use the finding board to agree/disagree

docs/demo.md:8 · MEDIUM — No handling of non-integer values in date components
The function assumes the split parts of the string can always be converted to integers, but if any part contains letters or symbols (e.g., 2024-01-XX), int() will raise a ValueError and crash the program.

Fix: Add a try-except block around the int() conversions to catch and re-raise a clear error message.

Proposed replacement (one-click ⚡ Apply on the findings board at the top of this PR):

    try:
        return int(y), int(m), int(d)
    except ValueError:
        raise ValueError("Date components must be integers")

_{panel tally 3/4 · reply here or use the finding board to agree/disagree}

**`docs/demo.md:8`** · MEDIUM — No handling of non-integer values in date components The function assumes the split parts of the string can always be converted to integers, but if any part contains letters or symbols (e.g., `2024-01-XX`), `int()` will raise a `ValueError` and crash the program. > **Fix:** Add a `try-except` block around the `int()` conversions to catch and re-raise a clear error message. **Proposed replacement** (one-click ⚡ Apply on the findings board at the top of this PR): ``` try: return int(y), int(m), int(d) except ValueError: raise ValueError("Date components must be integers") ``` panel tally 3/4 · reply here or use the finding board to agree/disagree

A-Guevara added a new dependency

2026-09-23 17:28:07 +00:00

tti/boards-demo#5 - Migrate icons to an SVG sprite

A-Guevara removed a dependency

2026-09-23 17:28:10 +00:00

tti/boards-demo#5 - Migrate icons to an SVG sprite

hello / hello (push) Successful in 14s

Details

ai-review / review (pull_request) Successful in 1m8s

Details

This pull request can be merged automatically.

This branch is out-of-date with the base branch

You are not authorized to merge this pull request.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin demo-change:demo-change

git switch demo-change

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch main

git merge --no-ff demo-change

git switch demo-change

git rebase main

git switch main

git merge --ff-only demo-change

git switch demo-change

git rebase main

git switch main

git merge --no-ff demo-change

git switch main

git merge --squash demo-change

git switch main

git merge --ff-only demo-change

git switch main

git merge demo-change

git push origin main

Sign in to join this conversation.

No reviewers

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

tti/welcome!1

Rows
Columns