M-UX: capture leaves the user's workflow

[MongLong0214]

SSOT outcome contract

This issue tracks the product outcome only. Implementation is owned by #527, R2-01, #550, #583, #424 fallback work, and R2-02 certification. Close only after the R2 milestone exit criteria pass.

---

ADR-0030 is Accepted and its shipping condition — "not before M5's verdict and the release that follows it" — is now met. M5 is published and v0.7.1 shipped.

The product this closes the gap to

install → code as usual → the judgment worth keeping is captured → validated → preserved in Git → handed to the next agent
                                            ↑
                                    the only manual step left

Delivery, validation and preservation already run without the user. The PreToolUse hook injects active records before an edit, commit-msg validates every commit, and trailers travel with a clone. Capture still waits to be asked.

A user who has to remember "record this in CommitLore" is a user for whom the tool is worth much less. The act of recording has to disappear from the workflow.

What ADR-0030 already decided

1. Unattended by default — the skill's step 4 is removed; capture prepares, verifies and stages without asking
2. Provenance: drafted for anything staged without recorded human review; SPEC §3 gains the value, grade.ts caps it at claim, a conformance fixture pins both sides
3. Promotion is a new record, not an edit — a commit message is immutable, so a reader who stands behind a drafted record writes one that Supersedes: it with Provenance: authored
4. Promotion is optional and rare — a repository where nobody promotes anything is one where every record is a claim, which is what every installed CommitLore serves today. The user doing nothing is the supported path, not a fallback.
5. An off switch, living with the capture policy ADR-0021 §7 already hashes

The cost the ADR names and does not mitigate

With no person in the loop the pipeline decides what is worth recording, and the skill's own guidance is that most commits carry nothing and {"records": []} is the common correct answer. A record costs a future reader attention; unattended capture spends that budget without asking.

That is the thing to watch. A tool that fills a repository with records nobody needed is worse than one that asks. Whatever ships has to be measured on how often it records nothing, not only on whether it records the right thing when it does.

Suggested split

• drafted in the vocabulary — SPEC §3, grade.ts cap, conformance fixture. Additive and safe on its own: a reader that does not know it falls to unknown, which also grades claim.
• The pipeline runs without asking — remove step 4, stage through the existing hooks
• The off switch — into the hashed capture policy
• A silence measurement — what fraction of commits it records nothing for, on this repository's own history. The ADR's stated cost deserves a number before this is called done.

Blocked on nothing. Two of the three open questions in What this does not decide remain open and the ADR was written so either answer stays safe.

[MongLong0214]

Design review: BUILD DIFFERENTLY. Two findings, both verified against the code.

1. The invariant in the ADR's title holds in auto and is unprovable in suggest

src/core/capture-verify.ts:258 stamps Provenance: drafted only when the policy mode is auto. suggest is deliberately left alone, and the comment says why:

suggest is left alone: a host in that mode may have asked, and stage has no way to tell whether it did (ADR-0028), so overwriting would be a claim this code cannot support either way.

That reasoning is right. The consequence is that "an unread record cannot direct an agent" is a property of auto mode, not of the pipeline. A suggest-mode host that skips its prompt and writes Provenance: authored produces a record that becomes a directive the moment trusted authors are configured.

What this changes about the plan: unattended capture ships as auto, and the ADR's central claim gets the qualifier it actually has. It is not a hole to patch — patching it would mean stage asserting something it cannot observe, which is the failure ADR-0028 recorded. It is a scope statement that was missing.

2. The failure mode nobody wrote down: accidental disclosure

Verification establishes that a drafted record is supported by the transcript and diff. It does not establish that the content is safe to publish.

Staging accepted text without displaying it can fossilise credentials, customer identifiers, incident details or private reasoning into commit messages — and trailers are immutable. A bad record is retired with Supersedes:, never deleted. The prompt being removed was the last redaction opportunity, and the ADR's cost section does not mention this at all. It names noise and it names that removal is expensive; it does not name that the thing being removed is a human's last look at the text.

This is now the highest-severity open question on this milestone.

3. Silence is the right instrument for the wrong half

Measuring how often the pipeline records nothing tests selectivity. It misses false negatives among the silent commits, false positives among the emitted ones, duplication, factual quality, and sensitivity. And historical commits lack the transcript context the pipeline would actually have had, so this repository's history is not representative ground truth for a shadow run.

Silence stays, paired with human-labelled precision and recall and a sensitive-data pass over what a shadow run would have written.

What did not break

No fixture pins the skill's step count — the step is instruction text only. Injection byte-identity is asserted three ways and is untouched unless rendering or the legend changes, which this does not. The capture policy hash takes mode as input and its tests already expect in-flight invalidation, which is the intended behaviour rather than a break.

Revised split

1. Unattended capture in auto mode — with the ADR's claim scoped to auto in writing
2. A redaction answer before anything stages unattended — this blocks the rest
3. The off switch
4. Silence, plus precision/recall and a sensitive-data pass over a shadow run

[MongLong0214]

The disclosure gate is half-built already. Measured, not reasoned.

I said accidental disclosure was the highest-severity item and that it blocked
the rest. It is narrower than that, and the part that is covered is covered by
something already shipped.

src/core/secret-guard.ts runs inside validate, which is what the
commit-msg hook runs. Its own header states the reasoning this milestone
needs:

A credential that reaches a commit message is permanent: rewriting history
does not reach the clones, forks and mirrors that already fetched it, so the
only moment the damage can still be undone is before the commit exists.
Hence a commit-msg hook rather than an audit.

An unattended record reaches a commit message through the same hook, so it is
scanned the same way. Verified against a real repository with a real
drafted record:

Limit: token is ghp_A1b2…                     ->  blocked
  shape failed
  3: github-token (high) — GitHub personal access, OAuth, app or refresh token
  commitlore: 1 possible credential (ADR-0005) — the message was not modified

The first probe used AWS's documented example key and passed, which is
deliberate: secret-rules.ts excludes it by name because people paste it into
commit messages legitimately, and a guard people habitually skip detects
nothing.

What that changes

Credentials are not the open question. They have a blocker, it fires on
unattended records, and it fires before the commit exists.

The open question is everything a regex cannot recognise: customer
identifiers, incident details, internal reasoning someone would not have
published. Those have no pattern, and the prompt being removed was the only
thing standing between them and an immutable message.

Revised severity

This no longer blocks item 1. It scopes it:

• unattended capture may stage anything the credential guard clears
• what it must not do is stage content a person would have redacted for a
  reason no scanner can express

The instrument for that is the sensitive-data pass over a shadow run, which
was already item 4. It moves ahead of the off switch and gets a stated bar:
a shadow run over this repository's own history, read by a person, with the
question "would you have published this?" answered per record — not "is it
supported by the diff", which is what verification already asks.

Correcting my own earlier comment: I wrote that the redaction answer blocks
everything. Half of it was answered before I filed the ticket.

[MongLong0214]

Closed by #517 and #519.

Unattended capture ships off by default, and init now asks once with yes as the default and recommended answer. commitlore auto on|off|status and the /auto command move the setting without anyone opening a JSON file.

The prompt names what the answer costs before it asks: the policy file is committed, so enabling applies to everyone who clones the repository.

The measurement this issue was originally blocked on is not resolved and is not pretended to be. The shadow instrument (#513) could not answer it from history, because historical commits carry no capture transcript. What it can do is answer it from live sessions — which is now reachable, since a repository can be opted in and observed.

[MongLong0214]

Reopening: this was closed against a release that does not contain it.

#525 is right, and the check is one command:

v0.7.1 = 12379345a3d5   →  src/commands/auto.ts absent
dev                     →  present

v0.7.1 was published on 2026-08-09. #517 and #519 merged into dev on
2026-08-11. The release came first, so no published artifact has ever carried
commitlore auto or capture --unattended.

Closing this as "shipped in v0.7.1" made a release note that a user can falsify
by running commitlore --help. That is worse than an unfinished issue: an open
issue is a known gap, and a wrong release note is a gap nobody is looking for.

Correct state: merged to dev, unreleased. This stays open until a release
contains it, and the release that does will say so.

Worth recording alongside this: #527 found that the enablement message
overstates what the four git hooks can do on their own. Capture needs a
transcript, and only an agent host produces one, so an ordinary hand-made commit
initiates nothing. That is being fixed separately — but it means "unattended
capture shipped" would have been the wrong phrase even in a release that
contained the code.