Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 7 additions & 5 deletions lib/commit-message.ts
Original file line number Diff line number Diff line change
Expand Up @@ -23,15 +23,17 @@ export const DEFAULT_MODELS: Record<Provider, string> = {

/** Caps keep latency low — short Conventional Commits don't need a big window. */
const MAX_DIFF_CHARS = 6000;
const MAX_COMPLETION_TOKENS = 64;
const MAX_COMPLETION_TOKENS = 96;
/** Soft target for the model prompt — we never hard-truncate the model output. */
const MAX_MESSAGE_CHARS = 100;
Comment on lines +27 to +28

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P2 The constant is named MAX_MESSAGE_CHARS but the accompanying comment explicitly says it is a soft target, not a hard maximum. The name implies enforcement that doesn't exist — cleanMessage no longer truncates, and the API cap (MAX_COMPLETION_TOKENS = 96) translates to roughly 300-380 characters at typical English token densities. Using the word "MAX" while the code says "we never hard-truncate" creates a false expectation for any reader or future maintainer. Renaming it to TARGET_MESSAGE_CHARS (or SOFT_TARGET_MESSAGE_CHARS) makes the intent immediately clear without needing to read the comment.

Suggested change
/** Soft target for the model prompt — we never hard-truncate the model output. */
const MAX_MESSAGE_CHARS = 100;
/** Soft target for the model prompt — we never hard-truncate the model output. */
const TARGET_MESSAGE_CHARS = 100;
Prompt To Fix With AI
This is a comment left during a code review.
Path: lib/commit-message.ts
Line: 27-28

Comment:
The constant is named `MAX_MESSAGE_CHARS` but the accompanying comment explicitly says it is a soft target, not a hard maximum. The name implies enforcement that doesn't exist — `cleanMessage` no longer truncates, and the API cap (`MAX_COMPLETION_TOKENS = 96`) translates to roughly 300-380 characters at typical English token densities. Using the word "MAX" while the code says "we never hard-truncate" creates a false expectation for any reader or future maintainer. Renaming it to `TARGET_MESSAGE_CHARS` (or `SOFT_TARGET_MESSAGE_CHARS`) makes the intent immediately clear without needing to read the comment.

```suggestion
/** Soft target for the model prompt — we never hard-truncate the model output. */
const TARGET_MESSAGE_CHARS = 100;
```

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!


const PROMPTS: Record<string, string> = {
en: `Git commit message generator. Reply with ONE line only.

Rules:
- Conventional Commits: "<type>: <description>" (feat|fix|refactor|style|docs|chore|test|perf|build|ci)
- English, imperative, lowercase description
- MAX 60 characters total. Short and specific.
- Aim for ~${MAX_MESSAGE_CHARS} characters. Prefer a complete message over cutting mid-word.

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P2 Soft target allows messages well beyond common git conventions. The prompt now says "Aim for ~100 characters", but most git forges (GitHub, GitLab, Gitea) wrap or truncate the commit subject line at 72 characters, and conventional practice recommends 50–72 chars. With a 96-token hard ceiling and no character truncation in cleanMessage, the model can legally produce subjects up to ~380 chars while technically satisfying the "~100 char" guideline. Consider tightening the target to ~72 (or keeping MAX 72) so generated messages display cleanly in standard git tooling.

Prompt To Fix With AI
This is a comment left during a code review.
Path: lib/commit-message.ts
Line: 36

Comment:
**Soft target allows messages well beyond common git conventions.** The prompt now says "Aim for ~100 characters", but most git forges (GitHub, GitLab, Gitea) wrap or truncate the commit subject line at 72 characters, and conventional practice recommends 50–72 chars. With a 96-token hard ceiling and no character truncation in `cleanMessage`, the model can legally produce subjects up to ~380 chars while technically satisfying the "~100 char" guideline. Consider tightening the target to `~72` (or keeping `MAX 72`) so generated messages display cleanly in standard git tooling.

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

- ONLY the message. No quotes, no period, no extra text.

Examples:
Expand All @@ -43,7 +45,7 @@ chore: bump project dependencies`,
Regras:
- Conventional Commits: "<tipo>: <descricao>" (feat|fix|refactor|style|docs|chore|test|perf|build|ci)
- Portugues, imperativo, minusculas na descricao
- MAX 60 caracteres no total. Curta e especifica.
- Almeje ~${MAX_MESSAGE_CHARS} caracteres. Prefira uma mensagem completa a cortar no meio da palavra.
- APENAS a mensagem. Sem aspas, sem ponto final, sem texto extra.

Exemplos:
Expand Down Expand Up @@ -92,10 +94,10 @@ export function cleanMessage(raw: string): string {

for (let i = lines.length - 1; i >= 0; i--) {
const candidate = stripEdges(lines[i]);
if (CC_RE.test(candidate)) return candidate.slice(0, 60);
if (CC_RE.test(candidate)) return candidate;
}

return stripEdges(lines[lines.length - 1]).slice(0, 60);
return stripEdges(lines[lines.length - 1]);
}

function extractResponseText(data: unknown): string {
Expand Down
Loading