The `suggest` policy names an approval that nothing can enforce

[MongLong0214]

From an external review of v0.5.0.

Measured

src/core/capture-policy.ts:

export type CaptureMode = 'suggest';

The pending transaction's phases, across src/:

prepared → verified → staged → applied → consumed

There is no approved, no rejected, and no approval token.

What that means

suggest reads as "produce a candidate rather than committing one automatically", and that is a real policy. But it is not an enforceable one: nothing in the transaction can represent "a human has seen this and said yes", so nothing can refuse to stage a record that was never shown.

Whether a candidate gets approval is currently a property of how a host skill happens to behave, not of the record's own state. Two hosts can disagree and both be within contract.

The UX this blocks

One decision worth keeping from this work:

  Checkout pricing is not reused for the admin quote — the two flows
  round and discount differently.

  [keep]  [skip]

with:

• at most one prompt per commit
• at most candidates
• skip is completely ordinary — most commits carry nothing
• editing re-verifies
• staging refused before approval
• silence on a trivial commit

Two ways in, and they are not equivalent

1. Host-side only. A skill withholds the stage call until the user answers. Ships fastest, changes no schema — but the contract is still unenforceable, and a different host can stage without asking.
2. A phase in the transaction. Approval becomes state the core can check, and stage can refuse. This changes the pending format, so it needs an ADR: ADR-0021 fixed the phase vocabulary and the identity-hash inputs, and a new phase touches both.

(1) is a reasonable first step and (2) is what makes suggest mean something. They should not be confused for each other.

Depends on

#340 — the skill is where the prompt would live either way.

[MongLong0214]

Fixed in #366, merged to dev.

Route (1) from the issue — the host-side prompt — is in skills/commitlore-commits/SKILL.md as step 4, between Verify and Stage. Route (2), an approved phase the core can check, is not built: it changes the pending format and the identity-hash inputs ADR-0021 fixed, so it needs its own decision. ADR-0028 records that, prices it, and states the trigger for revisiting.

The skill says plainly that nothing enforces the step, so the contract is not being claimed to be tighter than it is.

Closing manually: the default branch is main and releases are cut from it, so a dev merge does not trip GitHub's auto-close.