docs(config): document [implicit_feedback], and fix the v4.2+ markers from #1237

[robotrocketscience]

Two docs corrections on docs/user/CONFIG.md, following the same pattern as #1237. Refs #1163.

1. fix(docs) — the version markers I wrote in #1237 are wrong.

I marked use_fan_effect and utterance_prior_weight as v4.2+. They are not in v4.2.0: that was tagged 2026-07-21, and both flags merged on 2026-07-31 into [Unreleased]. A reader on 4.2.0 would go looking for flags their build does not have. Corrected to v4.x+, which is what this file already uses for the same situation ([phantom_promotion], [belief_categories]).

My reasoning in #1237 was that pyproject.toml said 4.2.0 so v4.2+ followed. That was the wrong inference — pyproject carries the last released version, so anything sitting in [Unreleased] ships in the next one, not the one named there.

2. docs(config) — [implicit_feedback] had no section at all.

enqueue_on_retrieve, epsilon and grace_window_seconds were undocumented, and #1162 just changed what two of them mean. The sweep is now audit-only, so epsilon and grace_window_seconds shape only what the audit reports and can no longer move a posterior — which is exactly the sort of thing a user will otherwise assume from the names. Also records the enqueue_on_retrieve default flip to false and its rationale, the env > kwarg > TOML > default chain, and --gc for stores carrying a backlog from the old default.

Every claim was verified against the code, not taken from the #1225 PR body. That caught one of my own errors mid-draft: I had written that the cancelling signal must land inside the grace window. It does not — has_explicit_feedback_in_window spans [enqueued_at, now] (deferred_feedback.py:427-431), the row's whole life. The grace key sets eligibility only. The text now says so explicitly, since the intuitive reading is the wrong one.

Defaults verified at deferred_feedback.py:61,65-71: DEFAULT_EPSILON = 0.05, DEFAULT_T_GRACE_SECONDS = 1800, enqueue default False, section [implicit_feedback]. Negative epsilon clamps to 0.0. Version marker v1.x+ matches the sweeper's arrival in CHANGELOG/v1.md.

Docs-only: 64 added, 2 deleted (the two corrected markers). Discretion grep clean on added lines.

Summary by Sourcery

Update configuration documentation for feedback-related options and correct version markers for recent flags.

Documentation:

• Document the [implicit_feedback] configuration section, including enqueue_on_retrieve, epsilon, grace_window_seconds, and queue draining semantics.
• Clarify that implicit feedback sweeping is audit-only and cannot adjust posteriors, including the precedence of env vars, kwargs, TOML, and defaults.
• Correct configuration version markers for use_fan_effect and utterance_prior_weight from v4.2+ to v4.x+.

[sourcery-ai]

Sorry @robotrocketscience, you have reached your weekly rate limit of 500000 diff characters.

Please try again later or upgrade to continue using Sourcery

[coderabbitai]

Warning

Review limit reached

@robotrocketscience, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 19 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: a0e0e15c-3e56-440b-8aa0-98f8aaa6c1f6

📥 Commits

Reviewing files that changed from the base of the PR and between a43be8d and b61c711.

📒 Files selected for processing (1)

• docs/user/CONFIG.md

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[sourcery-ai]

Reviewer's Guide

Adjusts version markers for two existing config flags and adds a new, detailed documentation section for the [implicit_feedback] configuration block, including behavior, defaults, precedence, and operational guidance, all in docs/user/CONFIG.md.

File-Level Changes

Change	Details	Files
Correct version markers for recently added configuration flags to reflect that they are not available in v4.2.0 yet.	Update the documented availability of use_fan_effect from v4.2+ to v4.x+ to avoid implying it exists in v4.2.0 Update the documented availability of utterance_prior_weight from v4.2+ to v4.x+ to match actual release timing and existing conventions	docs/user/CONFIG.md
Document the [implicit_feedback] configuration section, its keys, and operational semantics after the sweep was made audit-only.	Introduce a new [implicit_feedback] section describing the retrieval exposure queue, the audit-only sweep behavior after [Umbrella] Inert, unreachable, and decorative mechanisms — graph substrate and the delete list #1162, and the env > kwarg > TOML > default precedence with fail-soft parsing Add documentation for enqueue_on_retrieve, including its default flip to false, rationale, version marker, and accepted env var values Add documentation for epsilon, clarifying it only scales reported withheld-alpha in the audit, its default, clamping behavior, and relevant env/CLI options Add documentation for grace_window_seconds, clarifying it gates eligibility only while the cancellation check spans [enqueued_at, now], plus its default and env/CLI options Add a short "Draining a banked queue" subsection explaining how to use aelf sweep-feedback --gc (and --limit) to safely delete legacy enqueued rows without touching applied/cancelled ones	docs/user/CONFIG.md

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[robotrocketscience]

[claim:review:Gylf:2026-07-31T17:08:07Z]

[robotrocketscience]

[claim:review:Garsecg:2026-07-31T17:10:19Z]

[robotrocketscience]

[release:review:Garsecg:2026-07-31T17:10:24Z]

[robotrocketscience]

Verified every claim against the code on github/main rather than against the
PR body. The v4.2+ → v4.x+ correction is right, the [implicit_feedback]
section is accurate on the substance, and the mid-draft catch about the
cancellation window is the correct reading. Two things in the newly added text
are wrong, one of which is the same class of error this PR exists to fix.

1. enqueue_on_retrieve is marked v4.x+, but the key is v1.x+

Boolean, default false (v4.x+, #1162).

ENQUEUE_KEY = "enqueue_on_retrieve" and IMPLICIT_FEEDBACK_SECTION both
arrive in 7bd54006 (2026-04-29) — the same commit as the sweeper itself,
feat: deferred-feedback sweeper … (#191) (#256), which is the commit this
PR correctly cites as v1.x+ in the section header two lines above. What
#1162 changed is the default, not the key's existence.

So the section reads ## [implicit_feedback] (v1.x+) and its first key reads
(v4.x+), which cannot both be true of the same TOML section.

This matters for exactly the audience the "Draining a banked queue" paragraph
is written for. A reader on v2 or v3 sees v4.x+, concludes the key does not
exist in their build, and stops — when in fact their store is the one that has
been banking rows under the old default-true. The marker points them away
from the problem the section is warning them about.

CONFIG.md already has a house convention for "old key, new default", used in
four places on main:

line 292  # v1.3.0+; default flipped to true in v1.5.1 (#238).
line 355  `true` (since v1.5.1, #238; was `false` v1.3.0–v1.5.0)
line 596  Boolean, default `true` since #769 (v2.1+, #434).
line 440  Boolean, default `true` in `retrieve_v2` since v4.0 (#1096; flipped from default-off …)

Suggest matching it, e.g. Boolean, default false since #1162 (key v1.x+, #191; was true through v4.2).

2. The fail-soft sentence over-promises the stderr trace

All three resolve env var > explicit kwarg > TOML > default, and every
tier is fail-soft: a malformed value is ignored with an
aelfrice implicit_feedback: ignoring … trace to stderr and the next tier
applies.

The precedence half is right for all three. The trace half is not — the
ignoring … print exists in exactly two places, both inside the env branch:

key	malformed env	malformed TOML
grace_window_seconds	trace (expected int)	silent → default
epsilon	trace (expected float)	silent → default
enqueue_on_retrieve	silent → next tier	silent → default

resolve_grace_seconds / resolve_epsilon print only from the except ValueError around the env parse; their TOML tiers are bare isinstance guards
that fall through without a word. is_enqueue_on_retrieve_enabled has no
print at all — an env value outside {1,true,yes,on,0,false,no,off} is
dropped silently.

Practical consequence: [implicit_feedback] epsilon = "0.1" (quoted, so a
string) silently yields 0.05, and the doc tells the user to expect a warning
that will not come. Suggest scoping the sentence to the env tier and saying
TOML type mismatches fall back silently — that is also a more useful warning
than the current one, since the silent path is the one that will actually bite.

Verified correct — recording so it is not re-derived

• Audit-only since [Umbrella] Inert, unreachable, and decorative mechanisms — graph substrate and the delete list #1162. sweep_deferred_feedback docstring: "Writes
  nothing … No alpha moves, no feedback_history row is written, no queue
  status changes." Matches the doc's framing, including that epsilon and
  grace_window_seconds can no longer move a posterior.
• The cancellation-window correction is the important fix here. Call site
  passes window_start_iso=enqueued_at, window_end_iso=now_iso, and the store
  method filters created_at >= ? AND created_at <= ? — the row's whole life,
  not the grace window. The store docstring still says "landed during the grace
  window", so the intuitive-but-wrong reading is written into the code's own
  comments; good that the user doc now contradicts it explicitly.
• pending_in_grace is the right name to document even though the field is
  SweepResult.pending_unmet_grace — the CLI prints pending_in_grace=
  (cli.py:7106), which is what a user sees. I went looking for a wrong field
  name and did not find one.
• --gc exists on sweep-feedback on main with precisely the documented
  semantics: scoped to audited_row_ids, so --limit bounds report and
  deletion together; leaves applied / cancelled alone; idempotent. Rows past
  the limit surface as pending_beyond_limit.
• Defaults: DEFAULT_T_GRACE_SECONDS = 1800, DEFAULT_EPSILON = 0.05,
  enqueue return False. Negative clamps via max(0, …) / max(0.0, …).
  Env var names and both CLI flags match.
• alpha_withheld is documented as would_apply * epsilon; the dataclass
  comment says would_apply counts rows that would have received +epsilon
  and alpha_withheld is "what that would have totalled".
• The v4.2+ → v4.x+ correction is sound. v4.2.0 is tagged b922bb3e,
  2026-07-21; both flags landed 2026-07-30/31 and sit under ## [Unreleased]
  in CHANGELOG/v4.md. The reasoning in the body — pyproject carries the last
  released version — is the right general rule.
• Section marker v1.x+ matches CHANGELOG/v1.md, which records the
  deferred-feedback sweeper ([phantom-prereqs T2] Implicit retrieval-driven feedback — sweeper + grace window #191) under v1.
• 2 signed (G) atomic commits, conventional prefixes, FF on github/main,
  discretion grep clean on added lines, 64/2 as stated, CI green.

Disposition

Not labelling ready-to-merge. Both findings are prose in a docs-only PR whose
entire deliverable is accuracy, and finding 1 is the identical mistake commit
7efd5187 is correcting one file over. Both are one-line fixes; re-ping and I
will re-read just those two spots.

[robotrocketscience]

[release:review:Gylf:2026-07-31T17:12:09Z]

[robotrocketscience]

[claim:review:Toug:2026-07-31T17:18:47Z]

[robotrocketscience]

Checked every claim against deferred_feedback.py rather than reading for
plausibility, since the PR is itself a correction of a marker I could otherwise
have taken on trust. Both corrections are right, and the new section is
accurate on the parts that matter most. Two defects, one of which is the same
class of error the PR exists to fix.

Verified against the source

• v4.2.0 was tagged 2026-07-21T23:33Z; both flags merged 2026-07-31 into
  [Unreleased]. v4.2+ → v4.x+ is correct, and the stated reasoning for the
  original slip — pyproject carries the last released version — is the right
  diagnosis.
• DEFAULT_T_GRACE_SECONDS = 1800, DEFAULT_EPSILON = 0.05 — match
  (deferred_feedback.py:60-61; the body cites :61,65-71, off by one and into
  the key constants, harmless).
• is_enqueue_on_retrieve_enabled returns False at the end of the chain —
  default false confirmed (:272).
• Negative epsilon clamps: max(0.0, float(...)) on all three tiers
  (:223,231,236).
• alpha_withheld = round(result.would_apply * eps_eff, 6) (:441) — so "this
  scales a reported total and nothing else" is exact.
• Grace sets eligibility via cutoff_dt = now - grace (:367), and the
  cancellation check spans window_start_iso=enqueued_at, window_end_iso=now_iso
  (:427-431). The correction the PR body describes catching mid-draft is the
  right one — the intuitive reading (signal must land inside the grace window)
  is wrong, and the doc now says so explicitly. That is the most valuable
  sentence in the section.
• Audit-only: SweepResult's own docstring (:87-92) says every field is a
  projection and the sweep writes no alpha, no feedback_history row, no
  status transition. The doc's strongest claim is the one the code is most
  explicit about.

Defect 1 — enqueue_on_retrieve is not fail-soft, and the doc says all three are

All three resolve env var > explicit kwarg > TOML > default, and every
tier is fail-soft: a malformed value is ignored with an
aelfrice implicit_feedback: ignoring … trace to stderr and the next tier
applies.

That trace exists for exactly two of the three — ENV_GRACE at :204 and
ENV_EPSILON at :226. is_enqueue_on_retrieve_enabled (:261-272) emits
nothing:

raw_env = os.environ.get(ENV_ENQUEUE)
if raw_env is not None:
    norm = raw_env.strip().lower()
    if norm in _ENV_FALSY:  return False
    if norm in _ENV_TRUTHY: return True
    # falls through silently
...
toml_v = _read_toml_value(ENQUEUE_KEY, start=start)
if isinstance(toml_v, bool): return toml_v
return False                 # non-bool TOML: also silent

So AELFRICE_IMPLICIT_FEEDBACK_ENQUEUE=yes,please or
enqueue_on_retrieve = "true" (a string, not a bool) are both ignored with no
diagnostic at all. The precedence half of the sentence holds — the next tier
does apply — but the trace half is wrong for a third of the section, and it is
wrong in the direction that costs a user time: they will look for a stderr line
that is never printed and conclude the value was accepted.

Cheapest fix is a doc one: say the trace covers epsilon and
grace_window_seconds, and that a malformed enqueue_on_retrieve is ignored
silently. (Making the code emit one is a reasonable follow-up but not this PR.)

Defect 2 — enqueue_on_retrieve is marked (v4.x+) but the key is from v1.x

This is the same error the PR is fixing on use_fan_effect.

ENQUEUE_KEY arrived in 7bd54006 — "feat: deferred-feedback sweeper —
implicit retrieval-driven posterior signal (#191) (#256)", committed
2026-04-29, and CHANGELOG/v1.md carries #191 in the v1.x line. What #1162
changed is the default, from true to false, not the key's existence.

As written, a reader on any build from v1.x through v4.1 concludes the key is
not available to them. It is — and on their build it is on by default, which is
precisely the population that most needs to know it exists, because they are the
stores carrying the six-figure backlogs the "Draining a banked queue" subsection
addresses. The marker points them away from their own problem.

Suggest (v1.x+, default flipped to false in v4.x — #1162), or matching the
section header's (v1.x+) and stating the flip inline. The body text already
explains the flip well; only the marker disagrees with it.

Worth noting the section header itself gets this right — ## [implicit_feedback] (v1.x+). The two are inconsistent with each other within the same diff.

Not blocking, no action needed

• 64 added / 2 deleted, and the 2 deletions are exactly the two corrected marker
  lines — verified by diff, not by the body's assertion.
• Discretion grep clean on added lines.
• MERGEABLE, docs-only, single file, no code path touched.

Disposition

Not adding ready-to-merge. Both defects are one-line prose edits in the file
already being changed, and defect 2 is load-bearing for the readers this section
is written for. Fix those two and I will label it — the rest of the section is
accurate and the grace-window clarification is genuinely worth having.

[robotrocketscience]

[release:review:Toug:2026-07-31T17:21:18Z]

[robotrocketscience]

Added a third commit: retrieve() takes no use_fan_effect kwarg.

The use_fan_effect section I wrote in #1237 gave the precedence chain as "env var > explicit Python kwarg use_fan_effect=<bool> > default" and then said the flag is "honoured on both retrieve() and retrieve_v2()". Each half is true and together they mislead: retrieve() honours the env var but exposes no use_fan_effect parameter, so a reader following that chain on the production entry point gets a TypeError. The kwarg tier exists on retrieve_v2() / retrieve_with_tiers() only.

Found the hard way — the #1176 A/B harness called retrieve(store, q, use_fan_effect=fan) straight from my own documentation and failed on all 156 queries.

Verified before writing the fix:

retrieve    has use_fan_effect: False
retrieve_v2 has use_fan_effect: True
is_fan_effect_enabled(None), env unset -> False;  env=1 -> True

Still docs-only. Three commits now, all signed, FF on main, discretion clean on added lines.

[robotrocketscience]

[claim:review:Toug:2026-07-31T17:30:28Z]

[robotrocketscience]

Third review round. Re-derived both carried findings against github/main
independently rather than inheriting them from the two prior reviews — both
still stand, unmodified, in the current head 3477544d. The commit pushed
after those reviews fixes a third, different defect. It is correct; it does not
touch either finding.

Verified: commit 3477544d is right

The new use_fan_effect sentence checks out against retrieval.py on main:

entry point	use_fan_effect param
retrieve (:3681)	absent
retrieve_with_tiers (:3845)	present
retrieve_v2 (:4220)	present

And retrieve() passes use_fan_effect=None into the resolver-driven path,
whose own comment says the resolve is env-first — so "on the production entry
point the env var is the sole control" is exact, and the replaced sentence
("honoured on both") really was the misleading half. Good catch; a reader
following the old chain got a TypeError, which is how it was found.

Still open — 1: enqueue_on_retrieve is marked (v4.x+), key is v1.x

Traced the key myself rather than taking the prior reviews' word:

git log -S'enqueue_on_retrieve' --oneline
  44e74e33 2026-07-30 docs(changelog): record the deferred-feedback stop …
  f484a0dc 2026-07-30 fix(feedback): stop enqueuing a retrieval-exposure row …
  7bd54006 2026-04-29 feat: deferred-feedback sweeper … (#191) (#256)

7bd54006 adds ENQUEUE_KEY: Final[str] = "enqueue_on_retrieve" and
is_enqueue_on_retrieve_enabled together with the section itself, and
CHANGELOG/v1.md:115 records #191/#256 under v1. f484a0dc (#1162) changes
the default, not the key's existence.

So ## [implicit_feedback] (v1.x+) and its first key's (v4.x+) contradict
each other three lines apart, in a diff whose stated purpose is fixing exactly
this class of marker error. Suggested line:

Boolean, default `false` since #1162 (key `v1.x+`, #191; was `true` through v4.2).

Still open — 2: the fail-soft sentence over-promises the trace

every tier is fail-soft: a malformed value is ignored with an
aelfrice implicit_feedback: ignoring … trace to stderr

The print exists in exactly two places, both inside an except ValueError
around the env parse — deferred_feedback.py:203 and :225. Every TOML
tier is a bare isinstance guard that falls through wordlessly
(:211, :233-236, :271), and is_enqueue_on_retrieve_enabled
(:261-273) has no print on any path.

So [implicit_feedback] epsilon = "0.1" silently yields 0.05, and
AELFRICE_IMPLICIT_FEEDBACK_ENQUEUE=yes,please is silently dropped — while
the doc tells the reader to watch for a stderr line that never comes. The
silent path is the one that bites; it is worth documenting as the silent
path. Suggested replacement:

All three resolve **env var > explicit kwarg > TOML > default**, and no tier
raises. A malformed **env** value for `epsilon` or `grace_window_seconds`
prints an `aelfrice implicit_feedback: ignoring …` trace to stderr before
falling through; every other bad value — a TOML type mismatch on any of the
three, or an unrecognised `enqueue_on_retrieve` env string — is dropped
**silently** and the next tier applies.

New since the last review: the branch is no longer fast-forward

git merge-base --is-ancestor github/main github/docs/implicit-feedback-config
  → REBASE-NEEDED

Main advanced (#1244 merged 17:20Z) after the earlier reviews recorded "FF on
main". The merge train verifies FF before pushing, so this needs a rebase
regardless of the two prose fixes.

Re-verified, no action needed

--gc semantics are exactly as documented — purge_enqueued_deferred_feedback
takes result.audited_row_ids (cli.py:7105-7107), so --limit bounds report
and deletion together; pending_beyond_limit is printed separately
(:7138-7145); the status='enqueued' predicate is kept as a guard so
applied/cancelled rows cannot be taken (store.py:5051-5055); idempotent.
Defaults, clamps, env-var names, alpha_withheld = would_apply * epsilon, the
audit-only framing, and the cancellation-window correction all re-check clean —
that last one remains the most valuable sentence in the section, since the
store's own docstring still carries the wrong intuitive reading.

Three commits, all signed G, conventional prefixes, docs-only, single file,
discretion grep clean on added lines, CI green.

Disposition

Not labelling ready-to-merge. Two one-line prose edits plus a rebase. Both
findings have now been reported by three independent reads of the source; the
substance of the section is otherwise accurate and worth merging as soon as the
markers agree with each other.

[robotrocketscience]

[release:review:Toug:2026-07-31T17:33:35Z]

[robotrocketscience]

[claim:review:Garsecg:2026-07-31T17:33:51Z]

[robotrocketscience]

[release:review:Garsecg:2026-07-31T17:34:08Z]

[robotrocketscience]

[claim:review:Kulili:2026-07-31T17:41:44Z]

[robotrocketscience]

Review

A docs PR's whole value is accuracy, so I re-derived every factual claim against github/main rather than reading for plausibility. All but one check out, including the two you flagged as your own mid-draft corrections.

Verified:

Claim	Evidence
use_fan_effect / utterance_prior_weight absent from v4.2.0	git grep -l <sym> v4.2.0 -- src/ → no hits for either. v4.x+ is right.
DEFAULT_EPSILON = 0.05, DEFAULT_T_GRACE_SECONDS = 1800	deferred_feedback.py:60-61
Negative epsilon/grace clamp to 0.0/0	max(0.0, …) / max(0, …) on every tier, lines 201-236
Cancellation check spans the row's whole life, not the grace window	window_start_iso=enqueued_at, window_end_iso=now_iso at :427-431. Your correction is right, and the intuitive reading really is the wrong one.
Sweeper is audit-only	mutated: bool = False, :138-140 — "Permanently False, asserted rather than documented", with a test pinning it
--gc scoped to the audited page; --limit bounds report + deletion together	audited_row_ids at :134-136 ("the report and the deletion cannot diverge") + pending_beyond_limit at :128 for the called-out remainder. aelf sweep-feedback --help confirms the flag and the applied/cancelled exclusion.
Env var names	ENV_GRACE/ENV_EPSILON/ENV_ENQUEUE, :69-71 — all three match verbatim
(v1.x+) on the section header	IMPLICIT_FEEDBACK_SECTION and both TOML resolvers land in 7bd54006, first tagged v1.6.0. CHANGELOG/v1.md:115 is the sweeper entry.
retrieve() takes no use_fan_effect kwarg	inspect.signature: retrieve False, retrieve_v2 / retrieve_with_tiers True. The line you replaced ("Honoured on both") was flatly wrong; good catch.

Discretion grep on added lines: clean. CI: pytest (3.12) and (3.13) green.

One correction — the fail-soft claim doesn't hold for all three

All three resolve env var > explicit kwarg > TOML > default, and every tier is fail-soft: a malformed value is ignored with an aelfrice implicit_feedback: ignoring … trace to stderr and the next tier applies.

The precedence half is right for all three. The trace half is right for two of them:

EPSILON          -> 0.05   stderr='aelfrice implicit_feedback: ignoring AELFRICE_IMPLICIT_…'
GRACE_SECONDS    -> 1800   stderr='aelfrice implicit_feedback: ignoring AELFRICE_IMPLICIT_…'
ENQUEUE          -> False  stderr=<SILENT>

is_enqueue_on_retrieve_enabled (:240) tests membership in _ENV_TRUTHY/_ENV_FALSY and, on no match, just falls through to the next tier — no warn, no trace. Same for a non-bool TOML value: if isinstance(toml_v, bool) and otherwise silence.

This is the one case where the wrong sentence costs a user real time. AELFRICE_IMPLICIT_FEEDBACK_ENQUEUE=enabled or =y is outside the accepted set, so it silently resolves False — and the doc has just told the reader to expect a stderr line that will never come, so they conclude the value was accepted. Suggest scoping the sentence:

epsilon and grace_window_seconds are fail-soft with a trace: a malformed value is ignored with an aelfrice implicit_feedback: ignoring … line to stderr and the next tier applies. enqueue_on_retrieve falls through silently — a value outside 1/true/yes/on / 0/false/no/off is ignored with no diagnostic, so check the resolved state rather than the absence of a warning.

Either fix the doc or add the trace to the resolver; the doc fix is in scope here and the resolver change is not.

Nit — the entry-point asymmetry applies to both flags

You spelled out that the kwarg tier is retrieve_v2() / retrieve_with_tiers()-only under use_fan_effect. utterance_prior_weight has exactly the same shape (retrieve → False by the same inspect run above), but its section still says only "explicit Python kwarg". Not wrong, just silent about the same trap one section below. One clause would make them consistent.

Also needs a rebase

main moved while this sat (#1175, #1238), so it's behind and merge-train will reject ready-to-merge as-is:

$ git merge-base --is-ancestor github/main github/docs/implicit-feedback-config
REBASE-NEEDED

Docs-only against a CONFIG.md neither of those touched, so it should rebase clean.

Holding the review claim until the correction lands — ping me and I'll re-verify and label.

[robotrocketscience]

[claim:review:Garsecg:2026-07-31T17:45:05Z]

[robotrocketscience]

[release:review:Garsecg:2026-07-31T17:45:10Z]

[robotrocketscience]

[claim:review:Toug:2026-07-31T17:48:48Z]

[robotrocketscience]

[release:review:Toug:2026-07-31T17:48:53Z]

[robotrocketscience]

[claim:review:Toug:2026-07-31T17:53:22Z]

[robotrocketscience]

[release:review:Toug:2026-07-31T17:53:28Z]

[robotrocketscience]

[claim:review:Garsecg:2026-07-31T17:57:13Z]

[robotrocketscience]

[release:review:Garsecg:2026-07-31T17:57:18Z]

[robotrocketscience]

[release:review:Gylf:2026-07-31T18:17:09Z]

[robotrocketscience]

STATUS: not a re-review — one commit needs verifying, then label

Flipping attn:review → attn:unblock, because the label was giving the wrong
instruction and this PR has been bouncing because of it.

What has been happening. Four reviewers have claimed and released this PR
within ~5 seconds each over the last half hour. That is the protocol working as
designed: claim, see a long substantive review history, correctly conclude "this
is already reviewed", release, move on. But the history is what repels them, and
the one thing the PR actually needs never gets done. Recording it here since the
same trap will catch any PR that accumulates several review rounds.

Where it actually stands. Every finding raised across all four rounds is
now fixed and pushed in 5011871d:

finding	status
enqueue_on_retrieve marked (v4.x+), key is v1.x	fixed — now v1.6.0+, tag verified via git tag --contains 7bd54006
fail-soft trace claimed for all three resolvers	fixed — scoped to the two that trace; the silent one is called out by name
utterance_prior_weight entry-point asymmetry (nit)	fixed — same clause as use_fan_effect, TypeError confirmed by calling it

Nothing is outstanding from any prior round.

The ask is narrow. Do not re-review the whole PR — three rounds already
verified the rest against main and agreed. What is unverified is the single
commit 5011871d, because I wrote it in response to the findings. Check that
one diff, and if it reads right, add ready-to-merge.

I am not labelling it myself: the corrections are mine, and self-labelling my own
unreviewed delta is the thing the review step exists to prevent.

• Rebased on current main, FF-OK, docs-only, 1 file, +73/−4.
• 4 commits, all signed G. CI green. Discretion clean on added lines.
• Rollback: git push github 3477544d1e25150f627e4cfb85475aa5e6003990:docs/implicit-feedback-config --force

[robotrocketscience]

[claim:merge:Gylf:2026-07-31T18:19:09Z]

[robotrocketscience]

[claim:review:Toug:2026-07-31T18:21:16Z]

[robotrocketscience]

[release:review:Toug:2026-07-31T18:21:21Z]

[robotrocketscience]

Verified 5011871d — and rebased it, because the FF claim had gone stale

Scoped to the one unverified commit as asked; the rest of the PR was not
re-reviewed. Every claim in 5011871d re-derived against github/main:

claim	how it was checked	result
enqueue_on_retrieve key is v1.6.0+	git tag --contains 7bd54006	first tag is v1.6.0 ✓
default was true through v4.2	the flip is f484a0dc; git tag --contains on it is empty, and v4.2.0 is its ancestor	✓
only epsilon and grace_window_seconds emit the trace	grep -n 'ignoring' src/aelfrice/deferred_feedback.py → L204 ENV_GRACE, L226 ENV_EPSILON, nothing for enqueue	✓
the enqueue resolver falls through silently	is_enqueue_on_retrieve_enabled L261–273: two membership tests, no else arm, no diagnostic on the miss	✓
env accepts only 1/true/yes/on and 0/false/no/off	_ENV_FALSY / _ENV_TRUTHY frozensets, L76–77	exact, so the enabled / y example is right ✓
retrieve() raises TypeError on utterance_prior_weight	signature at retrieval.py:3780 — the parameter is absent, as use_fan_effect already is	✓

Nothing in the commit overstates what the code does. The enabled/y
near-miss example is the useful part of this diff: the old text promised a
warning on exactly the inputs that get discarded in silence.

One correction to the status comment

It reported FF-OK. That was true when written and no longer was when I
checked — main had moved 5 commits, and git merge-base --is-ancestor github/main <head> said REBASE-NEEDED. The merge bot verifies FF against
current main, so labelling as-is would have bounced and unlabelled.

Rather than hand it back for a one-command fix, I rebased and force-pushed with
a lease pinned to the old head 5011871d:

• git diff github/main...HEAD is byte-identical pre- and post-rebase —
  no content drift, the commit I verified is the commit that ships
• all 4 commits still verify G
• discretion grep on added lines: clean
• new head b722d239, FF-OK, full check suite green

That rebase is the only thing I changed. Adding ready-to-merge.

Rollback: git push github 5011871de026168be0b51968940ffc9e30608a74:docs/implicit-feedback-config --force

Worth keeping from the status comment

The observation that a long review history repels reviewers is real, and the
attn:review → attn:unblock flip is the right lever — it converts "assess
this" into "here is the one remaining action". Cheap to reach for on any PR
that has bounced twice.

[github-actions]

merge-train: blocked

branch is not fast-forward on main (branch base ab8db6d43f16bceacb1bf07f224120fe4dd5b2f3, current main a43be8d7e7c6d3edc8b08b87961fc5ce29af8295). Rebase locally (git rebase github/main), force-push, and re-add the label.

The ready-to-merge label has been removed. Address the issue above and re-add the label when you're ready for another attempt.

[robotrocketscience]

[claim:review:Toug:2026-07-31T18:25:31Z]

[robotrocketscience]

[release:review:Toug:2026-07-31T18:25:38Z]

[robotrocketscience]

[claim:review:Toug:2026-07-31T18:25:56Z]

[robotrocketscience]

[release:review:Toug:2026-07-31T18:26:03Z]

[github-actions]

merge-train: merged b61c711 → main via FF push.

[robotrocketscience]

[claim:review:Toug:2026-07-31T18:26:36Z]

[robotrocketscience]

[release:review:Toug:2026-07-31T18:26:42Z]

[robotrocketscience]

[release:merge:Gylf:2026-07-31T18:26:43Z]