[xwiki/xwiki-dev-llm] 4f0624: [Misc] Block unescaped GitHub autolinks in commit ...
Branch: refs/heads/commit-message-at-escaping Home: https://github.com/xwiki/xwiki-dev-llm Commit: 4f0624ca5bbfb958b12990c277bbee28d62b8f9c https://github.com/xwiki/xwiki-dev-llm/commit/4f0624ca5bbfb958b12990c277bbee... Author: Vincent Massol <[email protected]> Date: 2026-09-17 (Thu, 17 Sep 2026) Changed paths: M README.md M kimi.plugin.json M xwiki/hooks/hooks.json M xwiki/okf/conventions/commit-messages.md A xwiki/opencode/plugins/xwiki-commit-text.js A xwiki/scripts/check-commit-text.mjs M xwiki/skills/xwiki-pull-request/SKILL.md Log Message: ----------- [Misc] Block unescaped GitHub autolinks in commit and PR text with a hook * GitHub autolinks a bare `@name` in a commit body or PR body: `@since` links to and notifies the GitHub account of that name, an unrelated third party (`param`, `deprecated`, `Inject`, `Component`, `Override`, `UITest` and `Nested` are all real accounts too). A `#123` written by hand resolves against the GitHub repo, while XWiki's issues live in JIRA. Backticks suppress the autolink even though a commit message renders no other markup. * Enforce it with `check-commit-text.mjs`, a `PreToolUse` hook on `Bash` that inspects the message a `git commit` or `gh pr create`/`gh pr edit` would write and refuses it on a violation. The damage is unfixable after the fact — a pushed commit message can only be corrected by rewriting history on a shared branch — so this is blocked rather than documented and hoped for. Same rationale and shape as the line-ending guard: silent unless violated, Node, no always-on cost. * Parse a shell wrapper too: Claude Code resolves `bash -c "git commit …"` to the command `bash` and does not look inside the `-c` string, so a wrapped commit would otherwise bypass the check entirely. The inner script is re-parsed as a command in its own right, bounded to three levels. Scanning the raw command string instead was rejected: it blocks commands over text that was never a message, its advice (add backticks) is wrong for a shell command, and it cannot keep the summary-line exemption — 39 of 900 sampled commit subjects in these repos carry a bare `@` token. * Gate each handler with `if` (`Bash(git commit*)`, `Bash(gh pr*)`, and the three shell wrappers) so Claude Code matches the command string before spawning anything. Node's ~35 ms startup is the entire cost of this check — the check itself is 3 µs on a real commit and 224 µs on a 100 KB worst case — and without the gate every shell command would pay it. * Exempt the commit summary line: the convention is that it is the JIRA issue title verbatim, so it cannot take backticks. A bare token there is fixed by renaming the issue. Leave the `(#6304)` GitHub's squash merge appends alone. * Register the hook for all three hosts, with an opencode plugin wrapper reusing the same logic. * Document the rule in the commit-messages OKF topic and the `xwiki-pull-request` skill, and the capability in README.md. * Leave `xwiki/instructions/xwiki-org.md` and its byte budget untouched: the hook is what prevents a recurrence, so the always-on file does not need to carry the rule. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-dev-llm/settings/notifications
participants (1)
-
XWiki Notifications