docs(changelog): soften resolver + smart-binding prose per security-disclosure standard - #175
Conversation
…isclosure standard The 3rd-pass review's A5 audit flagged five phrases in this PR's CHANGELOG [Unreleased] entry that, taken together, broadcast a now-fixed weakness with a reproducible fingerprint and read as a regression target for anyone who can replay the eval pipeline. The user memory mem_01M0WKX6TR2YVRW12BRSAPHP4S paraphrases the pre-flagged "Do not broadcast security improvements or vulnerable details in changelogs" rule. The headline numbers the user explicitly wants preserved (k=50, savings_ratio 0.0 -> 0.4975, 35/36, 0/36, MRR 0.944 / 0.981, ~15 ms, 5/5 vs 0/5) are unchanged. Concrete redactions, by line in the original PR1 CHANGELOG: - Line 17 (Added): drops "Without this, every keyed write silently stored empty keys because the served gateway surface dropped the parameters." Re-narrates the Fixed bug; capability sentence kept. - Line 39 (Changed): drops the "(was 1/5 on the unkeyed benchmark pairs)" parenthetical. 35/36 and 0/36 numbers stay; the before/after ratio is what made the entry a regression-target tell. - Line 35 (Changed): reframes "without a stable `subject_key`" as a positive capability description (the aligned token-diff contract with explicit vetoes). The user pre-flagged this phrasing as a guide to a (now-fixed) weakness. - Line 53 (Fixed): drops "this is the underlying cause of the benchmark correction-miss pattern that the reworded-correction detector then had to compensate for." The two-flag coupling with line 35 reconstructed the silent-drop story end to end. Also adds one line to the cross-encoder bullet naming the file (`.env`) and the restart step explicitly, so the operator-facing enablement is unambiguous (per A2's readiness review). Owner-authored sections of CHANGELOG.md (Galaxy/dashboard/graph changelog entries below mine) are unchanged. CHANGELOG.md only. +14 -18. Follow-up to PR #171. Targeting ship/pr1-core-and-integration.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2d9a8012dd
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| regressions, MRR@5 lifts 0.889 -> 0.944 (sample) and 0.962 -> 0.981 (codemem), | ||
| with ~15 ms per query added. Not the default; flip with a one-line config. | ||
| with ~15 ms per query added. Not the default; flip with a one-line config | ||
| (`ENGRAPHIS_RERANK_MODEL` in `.env`, then restart the MCP server and dashboard). |
There was a problem hiding this comment.
Direct reranker setup to the trusted config file
When an operator follows this new instruction in a normal dashboard/MCP installation, Engraphis deliberately does not search the working directory for .env; it loads process variables or the owner-private ~/.engraphis/config.env instead. Restarting after editing ./.env therefore leaves ENGRAPHIS_RERANK_MODEL unset and the identity reranker active, so direct users to the trusted config file or process environment.
AGENTS.md reference: AGENTS.md:L40-L40
Useful? React with 👍 / 👎.
Per the open P2 review on PR 175: Engraphis deliberately does not
search the CWD for `.env` — process variables and the owner-private
`~/.engraphis/config.env` are the trusted sources. The previous
sentence ("ENGRAPHIS_RERANK_MODEL in `.env`, then restart ...")
would direct an operator to edit `./.env` and leave the identity
reranker active after restart. Now reads:
"set the value in the trusted config file
(`~/.engraphis/config.env` on the operator account, or as a
process environment variable) — Engraphis deliberately does
not read the CWD `.env`, so editing `./.env` and restarting
leaves the identity reranker active. Restart the MCP server
and dashboard after the change."
Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
Follow-up to #171. 3rd-pass review (8-agent audit) flagged five phrases in the
PR1 [Unreleased] CHANGELOG entry that, taken together, broadcast a now-fixed
weakness with a reproducible fingerprint and read as a regression target for
anyone who can replay the eval pipeline.
The user memory paraphrases the pre-flagged "Do not broadcast security
improvements or vulnerable details in changelogs" rule. Headline numbers the
user wants preserved (k=50, savings_ratio 0.0 -> 0.4975, 35/36, 0/36, MRR 0.944 /
0.981, ~15 ms, 5/5 vs 0/5) are unchanged.
Concrete redactions, by line in the original PR1 CHANGELOG:
empty keys" re-narration; capability sentence kept.
parenthetical. 35/36 and 0/36 numbers stay.
subject_key" as a positivecapability description (aligned token-diff contract with explicit vetoes).
correction-miss pattern that the reworded-correction detector then had to
compensate for."
Also adds one line to the cross-encoder bullet naming
.envand the restartstep explicitly, so the operator-facing enablement is unambiguous (per A2's
readiness review).
CHANGELOG.md only. +14 -18. Targeting
ship/pr1-core-and-integration(thePR1 branch, current tip 6cdfc57). Owner-authored sections of CHANGELOG.md
(Galaxy/dashboard/graph entries) are unchanged.