Closing a work item with a commit after the fact works for a commit that doesn't name it

g1t work close N --commit SHA (and MCP work_item close with commit) is documented as the way to land a work item after the fact. But closing_commit (services/work/src/items/landing.rs) refuses any commit whose own message doesn't already say Fixes #N, and a commit that says that would already have closed the item when it landed. So the escape hatch never works in the case it exists for.

On 2026-10-21, #339 was filed a minute after its fix (PR #338, commit 57f77aaa, merge 67847670). Neither commit names it, so g1t work close 339 --commit 6784767… was refused with "does not close #339", and #339 had to be closed by hand without its landing recorded.

Done when

• Explicit close: an explicit close with a commit accepts any commit on the repository's default branch from someone with the Write role. The explicit request is the attestation. It's recorded as a landing like any other, and the conversation says who tied it.
• Merge commits: it also accepts a merge commit of a pull request whose own work item, or whose description's Closes / Part of, names the item.
• Automatic closing is unchanged: closing from pushes and merges still needs a closing keyword.
• Tests: cover a commit that doesn't name the item (allowed with Write, refused without it), a commit not on the default branch (refused), and the merge-commit case.
• Docs: the work items guide and the CLI reference say what --commit accepts.