release/1.14.0

[tmseidel]

No description provided.

[max-california]

🤖 Agentic Code Review

Summary: this release bundles several useful improvements, but I found two blocking correctness issues in the new agentic-review/ctags work. I’d hold the PR until those are fixed.

Blocking findings

1. ctags-signatures output is not actually structured and will misclassify many members

File: src/main/java/org/remus/giteabot/agent/validation/ToolExecutionService.java
Lines: around 1016-1055, 1105-1135

The new formatCtagsSignatures(...) implementation renders each tag as a flat line, but the docs and tool description promise a compact architectural map of classes/methods/interfaces. Today it:

• does not group methods under their enclosing class/interface
• infers indentation only from scope != null, which is not enough to preserve structure
• will label any method whose name equals its scope as a constructor, even when the scope is not a class name in the relevant language/tagging mode

This is more than a presentation nit: the agent is being instructed to prefer this tool over cat for first-pass understanding, so misleading structure here can drive incorrect review conclusions.

Actionable fix:

• group tags by class/interface/module scope before rendering
• use both scope and scopeKind to decide whether a scoped symbol belongs under a container
• only apply the “method name equals scope => constructor” heuristic when scopeKind indicates a class-like scope

2. ctags-deps drops dependency information once ctags output is truncated

File: src/main/java/org/remus/giteabot/agent/validation/ToolExecutionService.java
Lines: around 1178-1188, 1272-1325

executeCtagsDepsTool() shells out via executeCommand(), which truncates stdout to MAX_TOOL_OUTPUT_CHARS before returning. formatCtagsDependencies() then parses that truncated JSON-lines stream.

For files with many imports/includes, truncation can cut the ctags output mid-line, silently producing partial dependency sets. Because the formatter ignores unparsable/incomplete lines, callers get a “successful” but incomplete dependency graph with no indication that it was truncated.

That is a correctness issue for a discovery tool explicitly meant to tell the agent what a file depends on.

Actionable fix:

• either bypass generic output truncation for ctags and cap after semantic parsing,
• or detect the truncation marker / incomplete final line and surface that the dependency list is partial,
• ideally both tools should parse full subprocess output first and only truncate the rendered result.

Non-blocking suggestions

Maven enforcer Linux rule may be unnecessarily strict

File: pom.xml
The new enforcer rule hard-fails all non-Linux builds. If that is intentional, fine, but it is a significant contributor workflow change. Consider whether CI/containerized guidance alone would be enough, or at least document this prominently in release notes.

AiIntegration now has both Lombok-generated and manual accessors for the same UI-facing property

File: src/main/java/org/remus/giteabot/admin/AiIntegration.java
The manual setEnableNativeToolCalling(...) is fine, but with @Data this class now mixes generated and custom accessors around a derived transient property. Not blocking, just worth keeping an eye on for serialization/binding surprises.

---

Read-only agentic review by AI Git Bot

• the first blocking Issue I cannot reproduce
• the second is not a Blocker, the limit is 10.000 chars, so this will be a rare edge case and we have to truncate the output...