Skip to content

chore(review): flag new tuple[...] returns in kbagent-pr-reviewer#400

Merged
padak merged 1 commit into
mainfrom
chore/reviewer-tuple-return-check
Jun 4, 2026
Merged

chore(review): flag new tuple[...] returns in kbagent-pr-reviewer#400
padak merged 1 commit into
mainfrom
chore/reviewer-tuple-return-check

Conversation

@padak

@padak padak commented Jun 4, 2026

Copy link
Copy Markdown
Member

What

Teaches the kbagent-pr-reviewer subagent to surface newly-added tuple[...] return annotations during review (Step 3.8 — Convention compliance).

Why

CONTRIBUTING.md requires semantically-distinct multi-value returns to use a @dataclass, never a bare tuple. Unlike the error_code enum rule, "semantically distinct" is subjective, so it can't be a deterministic CI gate the way scripts/check_error_codes.py is. It therefore slipped past CI to an LLM/human review on #387 — the _fetch_flow_schema / fetch_flow_schema tuple[dict | None, str | None] that became the FlowSchemaFetch dataclass.

This closes the loop: the reviewer now has a concrete, reproducible step instead of relying on remembering the rule.

How

In Step 3.8, adds a grep over the PR diff that finds added -> tuple[...] annotations (skipping variadic tuple[X, ...]), plus a judging rubric so the reviewer:

  • ignores the ~63 grandfathered returns (only diff-added ones count);
  • skips the BaseService parallel-result shape and worker callbacks;
  • flags a newly-added heterogeneous tuple of semantically-distinct values as NON-BLOCKING with a @dataclass recommendation.

Scope / notes

  • Touches only plugins/kbagent/agents/kbagent-pr-reviewer.md — internal review tooling, not in the Plugin synchronization map, no CLI surface, no version bump, no changelog entry needed.
  • kbagent-pr-reviewer.md is 23 KB, well under the agent-prompt budget (and it has no byte-budget test — only keboola-expert.md does). make check is unaffected (no .py change).

Open in Devin Review

CONTRIBUTING.md requires semantically-distinct multi-value returns to use a @DataClass, not a bare tuple. That rule is subjective ('semantically distinct'), so unlike the deterministic error_code check it cannot be a CI gate -- it slipped past CI to an LLM/human review on #387 (the FlowSchemaFetch finding).

Adds to the reviewer's Step 3.8 a grep that surfaces '-> tuple[...]' return annotations added in the diff (skipping variadic 'tuple[X, ...]'), plus a judging rubric: ignore the ~63 grandfathered returns and the BaseService parallel-result shape; flag a newly-added heterogeneous tuple of semantically-distinct values as NON-BLOCKING with a @DataClass recommendation.
@padak padak merged commit 21f9d47 into main Jun 4, 2026
4 of 5 checks passed
@padak padak deleted the chore/reviewer-tuple-return-check branch June 4, 2026 21:58

@devin-ai-integration devin-ai-integration Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 1 additional finding.

Open in Devin Review

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant