Skip to content

fix: retrospective review fixes for merged PR #57#109

Merged
ikeikeikeike merged 1 commit into
mainfrom
fix/retro-review-pr57
Jul 16, 2026
Merged

fix: retrospective review fixes for merged PR #57#109
ikeikeikeike merged 1 commit into
mainfrom
fix/retro-review-pr57

Conversation

@ikeikeikeike

Copy link
Copy Markdown
Member

Retrospective /code-review sweep of merged PR #57 ("fix: retrospective-review follow-ups for v0.9.18 (#48-#54)") that shipped without pre-merge review.

The one confirmed still-live bug is in PR #57's own self-review fix (commit 6ae5b94, "structured fallback so the data-loss guard does not leak sibling secrets"). sanitizeObservation falls back to structuredScrub/walkScrub only when the byte-level regex scrub turned a secret-keyed unquoted scalar into invalid JSON (e.g. {"token":12345678}{"token":[REDACTED]}). That fallback's secretKeyRE was anchored (^(...)$), so it only matched a bare key like token — but real tool/API JSON almost always uses a compound key: access_token, refresh_token, client_secret, auth_token. For {"access_token":12345678}, the byte-level scrub still breaks JSON validity (the substring token inside access_token matches secretPattern, same as the byte-level scrub always has), correctly triggering the fallback — but the fallback's exact-key gate then fails to match access_token, falls through walkScrub's default case, and returns the numeric secret completely unredacted while still reporting valid JSON. That defeats the very guarantee the fallback was written to provide, and is a straight secret-leak into the persisted observations.jsonl corpus.

Fix: drop the anchors so secretKeyRE substring-matches a key the same way secretPattern already does at the byte level, restoring consistency between the two redaction paths. Added TestSanitizeObservation_CompoundSecretKeyNotLeaked covering access_token / refresh_token / client_secret / a nested-under-array case; all fail before the fix and pass after.

Also reviewed (no further still-live issues found): monorepo-root project-id resolution (inject, observer run-once, dispatchInjectContext), whole-word user-prompt confidence-demotion scanning, escaped-JSON secret redaction, observer stop pid re-verify before SIGKILL, doctor's homunculus obs path, instinct promote preview-by-default, chooseBase branch_strategy trimming, and claudemd --write stale-proposal clearing — all correct as merged. The two items PR #57 explicitly deferred (observer grandchild process-group kill; a precise correction-of-assistant demotion signal) were already resolved by PR #58.

Test plan

  • go build ./...
  • go test ./... (all packages green)
  • golangci-lint run ./... (0 issues)
  • gofumpt -l on changed files (no diff)

Retrospective review of merged PR #57 found a still-live leak in its own
self-review fix (commit 6ae5b94, "structured fallback so the data-loss guard
does not leak sibling secrets"). sanitizeObservation falls back to
structuredScrub/walkScrub only when the byte-level scrub turned a secret-keyed
UNQUOTED scalar into invalid JSON. That fallback's secretKeyRE was anchored
(`^(...)$`), matching only a bare key like "token" — but real tool/API
responses almost always use a compound key: "access_token", "refresh_token",
"client_secret", "auth_token". For `{"access_token":12345678}`, the byte-level
scrub still breaks JSON validity (substring "token" inside "access_token"
matches secretPattern) and triggers the fallback, but the fallback's exact-key
gate then fails to match "access_token", falls through to walkScrub's default
case, and returns the numeric secret completely unredacted while still
reporting valid JSON — the exact leak this fallback exists to prevent.

Fix: drop the anchors so secretKeyRE substring-matches a key the same way
secretPattern already does at the byte level, keeping the two redaction paths
consistent. Adds TestSanitizeObservation_CompoundSecretKeyNotLeaked covering
access_token / refresh_token / client_secret / a nested-array case.
@ikeikeikeike
ikeikeikeike merged commit 813093f into main Jul 16, 2026
11 checks passed
@ikeikeikeike
ikeikeikeike deleted the fix/retro-review-pr57 branch July 16, 2026 06:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant