maint-fix(doc_drift): 2026-05-30-043001

[jaidhyani]

Automated fix attempt for the doc_drift check, from maintenance run 2026-05-30-043001.

This PR addresses a single concern (doc_drift). Other failing checks, if any,
get their own PRs.

See autofix_summary.doc_drift.md and autofix_session.doc_drift.log in
/Users/jai/.luthien/automated_maintenance/runs/2026-05-30-043001/ for details.

Review carefully — these changes are not human-authored.

---

Posted by automated autofix

[github-actions]

CHANGELOG reminder — This PR has no changelog fragment.

Add a file to changelog.d/ (see changelog.d/README.md for format).
If this is a chore/infra-only change, add the skip-changelog or chore label to suppress this reminder.

[claude]

Review

Verdict: LGTM. This is a one-line correction to the policy table in ARCHITECTURE.md, replacing an inaccurate description with one that matches the code.

Accuracy check (the core question for a doc-drift fix)

• Old: "Regex-based text substitution."
• New: "Literal string find-and-replace (optional case-insensitive matching)."

Verified against src/luthien_proxy/policies/string_replacement_policy.py:

• The user-facing config is replacements: list[list[str]] — literal [from, to] string pairs, not regex patterns.
• Default path (match_capitalization=False) uses plain str.count() + str.replace() (lines 251–253) — no regex at all.
• The match_capitalization=True path does compile a regex, but with re.escape(from_str) + re.IGNORECASE (line 201) — so the regex is purely a vehicle for case-insensitive literal matching, not user-supplied patterns.

The new wording is accurate and the old "Regex-based" wording was actively misleading (it implied users could pass regex patterns, which they can't).

Consistency with sibling docs

• README.md:277 already says "Fast string find-and-replace" — the new ARCHITECTURE.md row now aligns with that framing. Good.
• One thing this PR doesn't address (out of scope, but worth flagging as follow-up doc-drift): docs/policies.md:226 still reads "…uses pure string/regex matching." That phrasing has the same drift problem and could be tightened to drop the "/regex" part.

Minor observation (non-blocking)

The new one-liner doesn't mention the capitalization-preservation behavior (when match_capitalization=True, e.g. "COOL" → "RADICAL"). For a single-row table summary alongside terse entries like "Pass-through. Default.", that brevity is fine. The full behavior is documented in docs/policies.md and the class docstring.

Other dimensions

• Bugs / performance / security: N/A — docs only.
• Test coverage: N/A — no code change.
• Code quality: N/A — docs only, no formatting concerns.

Safe to merge.

[jaidhyani]

Addressed the CHANGELOG reminder: added a changelog fragment at changelog.d/maint-fix-doc-drift-2026-05-30.md (category: Chores & Docs) in commit 272ff16, per the conventions in changelog.d/README.md.

This was autonomous overnight work from the nightly sitrep agent — please review before any further action. The PR remains a draft.

[claude]

Review

Verdict: LGTM — fix is accurate, properly scoped, and process-compliant.

Correctness of the fix

Verified against src/luthien_proxy/policies/string_replacement_policy.py:

• The case-sensitive path uses literal result.count(from_str) / result.replace(from_str, to_str) (lines 251–253).
• The case-insensitive path does compile regex (_compile_case_insensitive_patterns, line 192), but only via re.escape(from_str) with re.IGNORECASE — i.e. regex is an implementation detail for case-insensitive literal matching, not a user-facing regex contract.
• The user supplies literal [from, to] string pairs in config, never regex patterns.

So "Regex-based text substitution" was genuinely wrong (or at least very misleading), and the new wording matches both the code and README.md line 279 ("Fast string find-and-replace").

Style / nits (non-blocking)

• (optional case-insensitive matching) is accurate but understates the more interesting behavior: when match_capitalization=True, the policy also preserves the capitalization pattern of the matched text (ALL CAPS → ALL CAPS, Title → Title, mixed → char-by-char). Consider: Literal string find-and-replace (optional case-insensitive matching with capitalization preservation). — table is already wide though, so not worth fighting over.
• Changelog fragment is well-formed: correct frontmatter, correct category (Chores & Docs), correct PR number. Filename maint-fix-doc-drift-2026-05-30.md diverges slightly from the actual branch handle maint-fix/doc_drift/2026-05-30-043001 but changelog.d/README.md only suggests branch-name-matching as convention, not a rule.

Process

• One concern, one PR ✓ (CLAUDE.md "One PR = One Concern").
• Docs-only change, so no test coverage requirement applies.
• No COE needed (CLAUDE.md scopes COE to bug-fix PRs).

Risk

Effectively zero — single-line description in a markdown table plus a new changelog fragment. No code paths touched, no behavioral change.

Safe to merge once CI is green.

🤖 Posted by an automated review agent

[scottwofford]

Claude-generated merge-queue triage of all open Luthien PRs, requested by Scott (Jul 7, 2026). Advisory only; Scott has not yet acted on these recommendations.

Recommendation: mark ready and merge.

One-line documentation correction, verified still needed: ARCHITECTURE.md line 121 on main still describes StringReplacementPolicy as regex-based, while the implementation is literal find-and-replace. CI is green, the changelog fragment landed in the June 10 follow-up, and the identical pipeline's previous run (#791) merged without issue. Note for a future pass: docs/policies.md line 226 carries the same drift.