fix(runtime): classify secret-gate source notation

[ohdearquant]

Summary

• Bound entropy-trigger context to the candidate sentence and report the exact contributing hex span, so refusal excerpts identify the actual candidate (secret gate: refusal excerpt names a non-hex word for hex-credential-token, and pattern-name vocabulary self-triggers refusals #2056).
• Recognize canonical repository revision URLs and exact HTML commit hrefs while keeping direct credential labels fail-closed (secret_gate: high-entropy-token fires on boundary-anchored prose compounds while identical substrings inside camelCase identifiers pass #2076).
• Exempt structurally recognizable dense LaTeX only when it contains no credential-shaped inner run; published secret-shaped RFC vectors remain intentionally fail-closed (secret gate: dense LaTeX trips high-entropy-token; published RFC test vectors trip hex-credential-token #1988).
• Make remediation guidance name sentence/paragraph boundaries that actually change the predicate, and document the resulting security contract.

Verification

• RED: the new secret_gate: high-entropy-token fires on boundary-anchored prose compounds while identical substrings inside camelCase identifiers pass #2076 repository-reference/guidance cases and secret gate: dense LaTeX trips high-entropy-token; published RFC test vectors trip hex-credential-token #1988 dense-LaTeX case failed before implementation; their must-block controls passed.
• GREEN: cargo test --manifest-path crates/Cargo.toml -p khive-runtime --lib issue_1988 -- --nocapture — 3 passed.
• cargo test --manifest-path crates/Cargo.toml -p khive-runtime --lib issue_2056 -- --nocapture — 2 passed.
• cargo test --manifest-path crates/Cargo.toml -p khive-runtime --lib issue_2076 -- --nocapture — 3 passed.
• cargo test --manifest-path crates/Cargo.toml -p khive-runtime --lib — 1,415 passed, 7 ignored.
• cargo clippy --manifest-path crates/Cargo.toml -p khive-runtime --all-targets -- -D warnings
• cargo fmt --manifest-path crates/Cargo.toml --all
• git diff --check

Security boundaries

Known-provider prefixes and inline credential assignments are unchanged. Repository references still block behind a direct credential label. LaTeX only exempts recognizable notation without credential-length hex or independently high-entropy alphanumeric runs. Exact public test-vector values do not receive a publication-based bypass.

Closes #2056
Closes #2076
Closes #1988

[ohdearquant]

CI is red at this head on a single root: khive-pack-git::acceptance ingest_masks_pr_body_hash_near_token_without_dropping_note
(crates/khive-pack-git/tests/acceptance.rs:1600). The other two red checks are
downstream of it — the aggregate gate, and the coverage job, whose Compute coverage step failed so its ratchet step never ran and produced no figure.

The failure looks like a genuine behaviour change rather than flake. Trigger
proximity is now evaluated within sentence bounds:

let near_trigger = contains_trigger(after_last_sentence_boundary(&window[..raw_start]))
    || contains_trigger(before_first_sentence_boundary(&window[raw_end..]));

The test fixture is:

Rotated the deploy token. Old hash was <64 hex chars> before rotation.

The trigger word token is in the first sentence and the hex run is in the
second, so the sentence break severs them, the run is no longer treated as
near a trigger, and the raw 64-hex value reaches stored content unmasked.

The boundary rules consider a period followed by an alphanumeric byte
intra-sentence, which keeps v1.2 intact, but a label and its value can
straddle a sentence break — ... token. Old hash was <value> is a common
shape in release and rotation notes. Narrowing trigger scope trades a false
positive for a false negative, and for a masking backstop the false negative
is the costly direction, so the assertion looks correct as written.

Suggested direction: keep the intra-token span refinement, which is the part
that improves reported match accuracy, and treat the sentence-boundary
narrowing of near_trigger separately — a label-to-value association that
survives one sentence break would keep this case masked without reintroducing
the broad windows the change is trying to tighten.

[ohdearquant]

Six red boxes on this head, but they reduce to two independent roots — worth separating before
anyone chases the wrong one.

Not signals: the two cancelled shards (ubuntu 1/2, macos 1/2) completed 17 and 23 seconds
after ubuntu 2/2 failed, so they are fail-fast siblings, not separate failures. CI gate started
after everything else finished and is a pure aggregator. And Coverage ratchet is red for a reason
that is not coverage: its Compute coverage step failed and Check coverage does not regress was
skipped, so no coverage was ever measured. That box is named for a judgment it did not make; it
will clear on its own once the build does.

Root 1 — a real regression, and it is on this change's own subject. ubuntu 2/2 ran 1867 tests
and exactly one failed: khive-pack-git::acceptance ingest_masks_pr_body_hash_near_token_without_dropping_note, panicking at
crates/khive-pack-git/tests/acceptance.rs:1600 with

raw 64-hex hash must not survive into stored content:
"Rotated the deploy token. Old hash was <64 hex chars> before rotation."

That is the relaxation landing wider than intended. The fixture is a sentence containing the word
token and a 64-character hex value — a length that is in the credential-length set — and after this
diff the value survives into stored content unmasked. The test is pre-existing and was passing, so
this is not a fixture that needs updating to match new behaviour; it is the case that says the gate
must still mask a credential-shaped hex value when a credential label sits beside it. Whatever
narrowing makes accurate matches accurate needs to leave that pairing flagged.

Worth checking alongside this: another open change to secret_gate.rs also relaxes the same gate for
UUID-shaped values near token prose. Each relaxation is defensible read alone, and their combination
is not obviously the union of two safe changes — whichever lands second should be re-validated
against the merged result rather than against the base it was written on, because both are widening
the same exemption surface.

Root 2 — the secret scan, which is almost certainly a fixture rather than a real credential. The
job reports leaks found: 1 and nothing more; CI runs gitleaks detect --source . --redact --no-banner (.github/workflows/ci.yml:385) with fetch-depth: 0 and there is no
.gitleaks.toml, so it scans full history under default rules and redacts its own output. The log
therefore names nothing.

What the tree shows, though, is quite specific. secret_gate.rs on main contains 52 hex runs of 32
characters or more and passes this scan, so hex length alone is not what trips it. What main has
zero of — and what the newest commit introduces exactly one of — is a binding whose name is a
credential keyword holding a long hex literal: let credential = "<40 hex chars>"; at
crates/khive-runtime/src/secret_gate.rs:3338. One new occurrence, one reported leak. Default
generic-secret rules key on precisely that identifier-next-to-high-entropy-value shape, which is also
the shape this crate's own gate is built to catch, so the fixture is doing to gitleaks exactly what
secret_gate.rs exists to do to callers.

I could not run gitleaks here to confirm it flagged that line, and the redacted log does not say, so
treat the specific line as a strongly-evidenced inference rather than a confirmed root — the counts
match and the baseline discriminates, but the tool has not been asked.

Scope, if it is that line: it appears only in the newest commit. The preceding commit's copy of the
file has zero such bindings, main has zero. So amending that commit clears it from history;
no rewrite of earlier commits is needed. Renaming the binding to something that is not a credential
keyword is the smallest fix and costs the test nothing, since the value's role in the test comes from
its shape rather than its variable name. An allowlist entry would also work but spends a permanent
exception on a temporary problem.

[ohdearquant]

This branch's head is currently turning the secret scan red on every other open pull request in the repository, not just this one. The mechanism is worth stating carefully because the finding itself is benign and the blast radius is not.

What gitleaks is matching. A single finding, generic-api-key:

f1c8e732e61b9ec2516b794dbb37afd5152cee59:crates/khive-runtime/src/secret_gate.rs:generic-api-key:3338

That line is a test fixture — a 40-hex-character constant bound to a credential-named local, used to exercise the secret gate's own detector. It is not a credential and nothing needs rotating. Reproduced locally with the same pinned version CI installs (v8.21.2), against a range containing only this branch's commit, with a must-match positive control in the same invocation and a commit-count assertion so an empty result could not read as clean.

Why it reaches other pull requests. .github/workflows/ci.yml checks out with fetch-depth: 0 and then runs:

gitleaks detect --source . --redact --no-banner

With no --log-opts, the scan population is every commit reachable from every ref in the checkout — the whole repository, not the change under review. A fetch-depth: 0 checkout carries all origin branches, so any commit pushed to any branch is scanned by every subsequent CI run on every pull request.

The timeline matches that exactly. This commit was pushed at 03:31:12Z:

secret scan started	result
03:28:38Z	success
03:36:03Z	failure
03:39:34Z	failure
04:00:57Z	failure

Every scan that began before the push is green; every scan after it is red, across changes that share no files with this one. Runs on main are still green only because main's most recent commit predates the push by two minutes — the same job runs on push: [main] and on the nightly schedule, so the next merge inherits it.

Two independent things to fix.

1. This branch. The constant needs a shape the generic-api-key rule does not match — built at runtime from parts, shortened below the entropy/length threshold, or moved behind a helper — rather than a .gitleaksignore entry. .gitleaksignore fingerprints are commit:path:rule:line, and the file's own comments record that this exact allowlist has already been re-pinned once when a later commit re-attributed the same two fixtures. A fingerprint pinned to a branch commit stops matching the moment the branch is rebased or squash-merged, so an allowlist entry here would need re-pinning at merge and would silently expire.

2. The scan's scope. A secret scan on a pull request should judge the commits under review. Passing --log-opts for the merge-base range would make each run's result a property of its own change; today a red scan on any pull request may be reporting a commit from an unrelated branch, with no way to tell from the log.

Worth adding -v at the same time. The current invocation prints only leaks found: N with no file, line, commit or rule, so every consumer of a red scan has to reproduce locally before learning anything — which is the only reason the cross-branch coupling above was not obvious immediately.

There is also a structural tension here that will keep recurring: the secret gate's tests must contain secret-shaped strings to test the detector, so this file is inherently adversarial to a repo-wide credential scanner. A scoped scan plus a deliberate fixture convention for this one module would settle it more durably than per-finding allowlisting.

[ohdearquant]

The red CI gate is subject-matter adjacent, not ambient

CI (ubuntu-latest, shard 2/2) fails one test:

FAIL khive-pack-git::acceptance ingest_masks_pr_body_hash_near_token_without_dropping_note
panicked at crates/khive-pack-git/tests/acceptance.rs:1600:5:
raw 64-hex hash must not survive into stored content: "Rotated the deploy token.
  Old hash was <64-hex fixture> before rotation."

Coverage ratchet also fails at Compute coverage, downstream of the same run.

This branch touches no file under crates/khive-pack-git/, which on several other branches
today has been a reliable sign that a failure is ambient. It is not that here, and the
distinction matters: that acceptance test exercises the masking behaviour this branch changes.
A 64-hex hash sitting near the word token is precisely the value-shaped-versus-label-shaped
case that source-notation classification decides, so an untouched crate says nothing when the
behaviour under test is the behaviour being reclassified.

Reading the assertion as a specification: the fixture wants the hash masked while the note is
still stored. The failure says the raw hash reached stored content, so the classification change
appears to have moved this input from masked to passed-through. Worth confirming against the
new notation rules directly rather than re-triggering, since a fresh run will reproduce it.

[ohdearquant]

This Secret scan red is real and specific to the change

The branch now carries the scoped scan, and the scope resolved correctly:

range="2e59ba274120389cf76f04a9cb2a97b9c841262a..370c6d6864e1fb04641770afe83f0cc5b05b931e"
2 commits scanned.
leaks found: 1

So this is not the unscoped whole-history form that was reporting the same ambient finding on
unrelated branches — it judged two commits, both of them this change's.

RuleID:  generic-api-key
File:    crates/khive-runtime/src/secret_gate.rs
Line:    3338
Finding: let credential = "REDACTED"

A literal on the right-hand side of let credential = ... matches generic-api-key on shape alone,
so a synthetic fixture trips it exactly like a real key would.

Suggested direction: build the fixture at runtime rather than allowlisting it. Something like
format!("{}{}", "AKIA", "0123456789ABCDEF"), or assembling it from bytes, keeps the test's
intent and leaves no literal in the tree for a scanner — or a reader — to match. That matters
independently of the check: this repository is public, and a committed string that reads as a
credential is a publication surface whether or not the value was ever live.

If you would rather allowlist it, one thing to know first: the fingerprint gitleaks emits is
commit-pinned —

f1c8e732e61b9ec2516b794dbb37afd5152cee59:crates/khive-runtime/src/secret_gate.rs:generic-api-key:3338

— so any amend, rebase, or squash of that commit changes the fingerprint and the entry stops
matching. It fails toward red rather than green, which is the safe direction, but it will look like
a new finding rather than a stale allowlist entry, and the line number pins it further.

[ohdearquant]

The sentence trim breaks label-to-value association, and an acceptance test already proves it

Narrowing trigger context to matched spans is the right idea. The sentence trimming goes one step
further than that, and it converts a masked value into a persisted raw one.

At this head both sides of the trigger context are trimmed to the current sentence:

// crates/khive-runtime/src/secret_gate.rs:969-971
let near_trigger = contains_trigger(after_last_sentence_boundary(&window[..raw_start]))
    || contains_trigger(before_first_sentence_boundary(&window[raw_end..]))
    || has_inline_credential_trigger(raw_token);

origin/main reads the whole window instead:

let near_trigger = contains_trigger(&window[..raw_start])
    || contains_trigger(&window[raw_end..])
    || has_inline_credential_trigger(raw_token);

Downstream there is no second chance. An off-trigger pure-hex token is allowlisted outright at
:997-999 (if !near_trigger && is_pure_hex(token) { continue; }), and collect_mask_spans then
copies the value through unchanged, so the predicate is load-bearing for the whole masking call
rather than just for entry into it.

The existing fixture "Rotated the deploy token. Old hash was <64 hex> before rotation." puts the
label and the value on opposite sides of a period, which is precisely the shape the trim discards.
This is not hypothetical: the macos shard fails
ingest_masks_pr_body_hash_near_token_without_dropping_note, panicking at
crates/khive-pack-git/tests/acceptance.rs:1600, with 92 passed and 1 failed. The production path
that reaches it is crates/khive-pack-git/src/ingest.rs:2251-2252, where a fetched body is passed
through mask_secrets before persistence.

The asymmetry is what makes this worth holding on. A false positive masks something harmless and is
fixed by rewording. A false negative writes credential-shaped content into durable storage, silently,
and nothing downstream re-checks it.

The new local test establishes that a detector name should not cross a sentence boundary. It does
not establish that a credential label and its value may safely cross one, and the acceptance test
asserts the opposite.

Suggested direction: keep the matched-span improvement, but do not let sentence scoping break
label-to-value association in the masking predicate. Either exempt the credential-label lookup from
the trim, or keep a separate fail-closed path for credential-shaped hex so that trimming can only
ever add coverage, never remove it.

For transparency on how this was produced: an automated pass over this diff ran on a model from the
same family as the one that authored it, so its output was treated as input evidence only. The three
load-bearing facts here — the trimmed predicate at this head, the untrimmed base version, and the
named acceptance-test failure in the macos shard log — were each re-derived directly before posting.

[ohdearquant]

Automated review. Posted by this repository's automated pull-request review pipeline; this is not a human read and does not gate the merge by itself.

Verdict on head 08be572: REQUEST-CHANGES, 3 blocking findings. Finding details are delivered to the review's recipients rather than posted here. Do not merge this head while blocking findings are outstanding; a pipeline comment on a newer head supersedes this one.

[ohdearquant]

Main is merged in and the branch is mergeable again. Two conflicts, both in the
entropy trigger path, resolved toward main's newer structure with this branch's
intent folded in rather than dropped:

• check_entropy_heuristic now calls main's entropy_trigger, which already
  carries the inline-credential check and adds the line-local rule for a bare
  Git-length value. The sentence-boundary narrowing this branch introduced moved
  inside that helper, so trigger context still stops at a sentence boundary. The
  preceding-label fallback stays exempt, since that line is already required to
  end in an assignment delimiter.
• The allowlist paragraph keeps both rules rather than either: the path, revision
  and LaTeX exceptions from this branch, and the line-local trigger rule for bare
  Git-length hex from main.

One test is red at this head and is deliberately not papered over:
forty_hex_bridge_fragments_keep_cross_line_detection_and_full_masking leaves
the second bridge fragment in the masked output. Three configurations were
measured, which narrows it usefully:

configuration	result
as pushed	only the bridge test fails (332 passed, 1 failed)
sentence-boundary narrowing removed	bridge test and issue_2056_detector_name_does_not_trigger_across_sentence_boundary fail
step 6 redaction target switched back to the whole token	bridge test and issue_2056_hex_bridge_masks_the_matched_candidate fail

So the narrowing is load-bearing and is not the cause, and step 6's return shape
is not the cause either: those are the two changes a reader would suspect first,
and each one only adds a second failure when reverted. The failure direction
matters here, since a surviving fragment in masked output is a leak rather than a
cosmetic difference, so this stays open until the cause is named.