No benchmark arm configures a trusted author, so the [directive] path the README's claims rest on has never been measured

[MongLong0214]

What I found

commitlore-on runs the real injector (commitlore inject --hook-input), and the ablation arms run buildInjection directly through the shim in bench/hooks-settings.ts. Neither passes --trusted-author, and src/commands/inject.ts defaults trustedAuthors to [].

gradeRecord is fail-closed on an empty list — "no trusted authors are configured, so X is an outside contributor" — so every record in every benchmark arm grades claim.

Measured, not inferred. Same seeded repo, one authored record, buildInjection both ways:

--- commitlore-on (real grading, no trustedAuthors) ---
Ruled-out
  [claim]      r-probe01  a4613ed5  shared Redis cache | ops refuses another stateful dependency

--- no-grade ---
Ruled-out
  [directive]  r-probe01  a4613ed5  shared Redis cache | ops refuses another stateful dependency

Two consequences

1. The directive path is unmeasured. The plugin instructions tell agents that [directive] means "treat as a constraint", and that is the routing the product's value claim rests on. No arm has ever produced one. M1 and M5 measured an agent reading records tagged [claim] throughout.

2. bench/types.ts describes no-grade incorrectly. It says:

Inert on a task whose records are all Provenance: authored, because there is nothing to promote.

That is true of bench/context.ts's assembleContext, which routes on record.provenance === "authored". But assembleContext is only reached when writeArmSettings returns settingsPath: null, which happens only when an arm has neither a preToolUse nor an ablation — so not for no-grade. On the real path no-grade flips every record from claim to directive, on the existing fixtures, today.

The comment matters because it is load-bearing: I wrote it into bench/PREREGISTRATION-M6.md §4 as the reason M6 needs new fixtures before it can run at all. It does not.

What this needs

• Decide whether the benchmark should configure a trusted author. It is a design choice, not an oversight to patch quietly: an arm with one measures the product as a repository actually configures it, and an arm without one measures the fail-closed default. Both are defensible and they answer different questions.
• Whichever is chosen, record it in the arm definition so a reader of a result knows which was measured.
• bench/README.md and any published number derived from M1/M5 should say that those runs measured claim-tagged records.

Related: #412 (M6), and bench/PREREGISTRATION-M6.md §4 needs correcting either way.

[MongLong0214]

Following this up turned out worse than filed. It is not only the benchmark.

The shipped hook cannot produce a [directive] either

src/hooks/claude-settings.ts:

export const CLAUDE_HOOK_COMMAND = `commitlore inject --hook-input ${CLAUDE_HOOK_MARKER}`;

No --trusted-author. src/commands/inject.ts defaults trustedAuthors to [], and gradeRecord is fail-closed on an empty list. So the hook commitlore init installs — the one every user gets — grades every record claim, in every repository, forever, unless someone hand-edits the settings entry.

Measured on a repository whose record was authored by its own committer:

record lines: 6
directive: 0   claim: 6

The benchmark is therefore not misconfigured relative to the product. It is configured exactly like the product. M1 and M5 measured what users actually get — which is better news for those results than the original report implied.

But the payload advertises a level it cannot deliver

src/core/inject.ts:

const legend = [DIRECTIVE_LEGEND, CLAIM_LEGEND, BLOCKED_LEGEND];

Unconditional. Every injection spends budget telling the agent that [directive] means "treat as an instruction" and that [blocked] withholds content — two tags that cannot appear in the shipped configuration. Against ADR-0006/PRD-F4's 800-token default that is real budget, and it is also the projection describing itself inaccurately, which render's own comment says is worse than saying less.

The plugin's MCP instructions carry the same claim: directive = recorded by a trusted author of this repository, still active: treat as a constraint.

What this actually needs

Not a quiet patch. Three separable decisions:

1. Should the product ship a way to configure trusted authors? Right now there is a --trusted-author flag no installed surface passes. Either the hook grows a source for it (git config, a repo file) or the flag is documented as advanced-only and the docs stop implying directive is the normal case.
2. Should the legend be conditional on what the payload contains? It would save budget and stop advertising unreachable levels.
3. What do the README and the plugin instructions say about a trust level nobody can reach as installed?

Deliberately not doing any of it yet

Changing the legend changes the injected bytes, which changes cacheKey and breaks the byte-identity test/inject.test.ts pins — the property that makes an arm comparable to the baseline at all. M5 is mid-flight against a pinned harness right now, and the release is gated on it. Touching injection bytes before it lands would put a second uncontrolled difference into a measurement that already carries three recorded deviations.

So: recorded here with the evidence, decided after M5's verdict. The one thing being corrected now is bench/types.ts's description of the no-grade arm, which is wrong on its own terms and which bench/PREREGISTRATION-M6.md §4 repeated.

[MongLong0214]

Closed by #447, merged to dev.

init now records the installing user's git identity as the repository's trusted author, so a record you authored reaches your agent as [directive] — the tier the injected legend has been advertising since the beginning and that no install could produce.

The threat model is unchanged: another author's commit still grades [claim]. It lives in commitlore.trustedAuthor local git config, so a team can widen it to its reviewers or unset it back to trust-nobody without hand-editing a hook.

The acceptance tests drive buildInjection through the options commitlore inject builds and assert on the rendered line — a unit test of gradeRecord would have passed throughout the entire period this bug existed.

M1 and M5 remain measurements of [claim]-graded delivery and their numbers do not transfer to the directive path; CDEB's protocol already forbids that confusion (PRD v1.2 §17.3).