Unattended auto reports enabled but ordinary commits never initiate capture

[MongLong0214]

SSOT execution contract

Outcome

On the certified Claude Code adapter, an eligible git commit attempt deterministically starts or finds a capture assessment without the user asking.

Scope

• host hook receives transcript/cwd/tool call
• robust commit-intent parsing
• one bounded Commit Gate retry
• existing pending transaction/hook pipeline reuse

Acceptance

• important change → record staged
• trivial change → verified-empty
• changed staged tree invalidates prior assessment
• direct human commit follows documented non-agent policy
• no infinite loop or model/network call in Git hook

---

Summary

commitlore init --unattended reports that unattended capture is enabled and describes it as preparing, verifying, and staging a record on every commit. A normal commit after successful initialization does not initiate capture: no pending transaction is created, no trailer is appended, and no note is written.

The installed hooks only validate/apply/finalize an already-staged pending record. They do not create the transcript/draft/pending transaction that commitlore capture requires.

Reproduction

Use current dev at 78f88be16413796845794d70465f60d7b919fe3f:

git init -b feature repro
cd repro
git config user.name 'E2E'
git config user.email 'e2e@invalid.local'
git commit --allow-empty -m 'chore: baseline'
commitlore init --unattended --verbose

Initialization succeeds and reports:

installed commit-msg hook
installed prepare-commit-msg hook
installed post-commit hook
installed pre-push hook
unattended capture enabled: wrote .commitlore-policy.json (mode "auto")

Commit the generated policy/config, then make and stage a non-trivial text change and run only the ordinary Git operation:

git add decision.txt
git commit -m 'docs: record the pinned runtime decision'

Observed readback:

shape ok · references ok

$ git show -s --format='%B' HEAD | git interpret-trailers --parse
# empty

$ commitlore pending ls --json
{"transactions":[],"unreadable":[]}

$ git notes --ref=commitlore list
# empty

The exact auto/init/prepare/post-commit focused suite passes, so this is not a hook installation failure.

Source boundary

• auto.ts reads/writes consent (mode: "auto", unattended: true).
• prepare-commit-msg applies only an existing staged pending record.
• post-commit finalizes only an applied pending record.
• capture.ts requires transcript and draft inputs to create and stage that pending record.

No installed Git hook initiates that first capture step.

Expected

The product needs one truthful contract:

1. If unattended auto is intended to start capture for every normal commit, initialization must install and verify the component that initiates capture, and the E2E above must yield either a verified record or an explicit verified-empty decision.
2. If an external host integration is required to invoke capture, init/auto status must name that prerequisite and must not report the repository as fully enabled when the host trigger is absent.

Failing silently is the unsafe state: the repository says unattended capture is on while ordinary commits produce no capture attempt and no diagnostic.

[MongLong0214]

Addressed on dev in #530, and the rest of it in #538. Merged to dev, unreleased.

Your second branch was the correct diagnosis. The pipeline was not broken: capture needs a transcript, the installed hooks can only apply and finalise an already-staged record, and by ADR-0028 no hook can produce a transcript from a diff. So an ordinary hand-made commit initiates nothing, and always will.

What was broken was the claim. init, auto status and doctor now separate consent from initiation, and doctor grew an unattended-initiator check.

One correction to the report: MCP is not the only initiator — commitlore capture --transcript … is another. Neither is invoked by an ordinary git commit, so the conclusion stands.

Two things worth recording, because the first fix was not enough:

The warning had to be clearable. The first pass warned whenever unattended was on, with no path to ok — right for an unwired repository, wrong for a correctly configured one, and unable to tell them apart. Every repository running this as intended would have carried a permanent warning, which teaches people to stop reading the surface that carries the real ones. It now passes when .mcp.json registers the capture server, and says registration-only in its evidence, because registration is configuration and not observation.

Nothing installed that registration. #538 makes init write it, merging with any existing file. Requiring four repositories to be wired by hand after init was the actual gap; the honest message was only half the fix.

[MongLong0214]

Field measurement, 2026-08-13, across five instrumented repositories all running v0.8.1.

The wording half of this is fixed: init --unattended now reports unattended policy enabled — agent host must initiate capture rather than describing a hook that prepares, verifies and stages on every commit. That matches ADR-0028 — a hook has the diff, and capture needs the transcript, which only the host has.

The substance is unchanged and now has numbers. Records by provenance:

repository	commits	records	drafted
commitlore	—	254	1
agent-operator-score	211	30	0
logic-pro-mcp	953	0	0
stock-ai-newsletter	1083	0	0
hermes-agent	21770	0	0

284 records, one of them drafted — and that one was written today by a headless session run specifically to prove the pipeline can work. Every other record is authored: an agent wrote the trailers directly, following the skill, without prepare_capture → verify_capture → stage_capture ever being called.

This is not an installation fault. Probed in each repository today: the server starts as commitlore 0.8.1, lists all seven tools including the three capture tools, and its instructions string contains prepare_capture. The mechanism is present and reachable in all five.

So the open question this issue names is the right one, and it is not "are the tools installed" — it is whether an agent that holds them ever reaches for them. Two of the five repositories have never produced a single record of any kind despite having had hooks and a registration for weeks.

v0.8.1 fixed the most likely cause on the read side: before it, the MCP instructions described only the read half of the protocol, so the four MCP-only hosts held the capture tools with nothing telling them what they were for. Whether that is sufficient is now measurable — every number above predates the fix, so none of them tests it. Re-measuring after sessions have run under v0.8.1 is what would answer this issue.

[MongLong0214]

Two corrections to the measurement above, both material.

1. The question this issue asks is now answered affirmatively, from a clean start.

Verified on v0.8.1: one install from the published tag, one init --unattended in a fresh repository, one headless agent session. The result in git:

git rev-list --count HEAD                              → 2
git log --format=%B | grep -cE '^Provenance: drafted'  → 1

with the transaction ledger showing the full lifecycle rather than a trailer somebody wrote — phase: consumed, consumed_by naming the commit, base_head, staged_diff_hash, staged_tree_oid, transcript and diff source_hashes, and three verbatim evidence quotes with transcript locators. Prepare → verify → stage → commit-msg consumption completed unattended.

So the mechanism works, and the reason it had not been working is consistent with what v0.8.1 changed: before it, the MCP instructions described only the read half, and the four MCP-only hosts held the capture tools with nothing saying what they were for. The handshake now returns instructions naming commitlore_prepare_capture, commitlore_verify_capture and commitlore_stage_capture in order.

2. My method for the table above was wrong, and I should say so.

I counted Provenance: drafted trailers in commit messages as the signal for "the pipeline ran". That trailer is hand-typeable — a commit carrying it with zero pending transactions is accepted by the hook, reproduced and filed as #583. The counts happen to be correct, because nobody was forging, but the method could not have detected it if they were.

The numbers therefore stand as a lower bound on pipeline-produced records, not a measurement of them. What would make it a measurement is #583's first option: join commits carrying drafted against the ledger and report which are backed by a consumed transaction naming that sha.

This issue stays open on its own terms. The pipeline is reachable and works when a host initiates it; whether hosts actually do so, across real sessions rather than one designed to prove it, is still unmeasured — and every number in the table predates the fix, so none of them tests it.