memory:promote — sibling-metric-noise-band-audit (PR #761 resolution)

[github-actions]

Lesson

Updates dev-mesh/curator/memory/workflows/sibling-metric-noise-band-audit.md (added by PR #762 after PR #758 fixed recall's noise band) with the resolution and a new finding from PR #761, which merged today closing #746 (precision regressed -15%) by gating precision: { noiseBandPct: 20 } alongside recall — the sibling-metric fix the workflow doc predicted would be needed.

New finding not previously captured: fixing the root cause does not retroactively close pre-existing duplicate issues that share the same finding natural key (<!-- mesh-scan:perf:<cell>:<metric> -->). A second mesh-scan run (11:30:14Z) refiled against the same three (cell, metric) pairs as three already-open first-run issues — #752 dup of #742, #754 dup of #744, #756 dup of #746 — before PR #761 landed. PR #761 only referenced #743/#744/#746 (and closed #746 via Closes); planPostMergeReconcile keys strictly off a merged PR's closingIssuesReferences, so #742/#754/#756 are now orphaned: still OPEN with no PR pointing at them, and nothing will close them automatically.

Added as step 5 in the workflow doc + updated the Evidence/Provenance sections to reflect the actual two-scan-run timeline and final state.

What to inspect

• dev-mesh/curator/memory/workflows/sibling-metric-noise-band-audit.md (updated, memory root only)
• No code touched; quick.json untouched and re-validated (node scripts/validate-quick-memory.mjs dev-mesh/curator/memory/quick.json → valid)

Housekeeping done outside this PR

Moved the source issue #746 to done (removed stale pr:in-review, added done) since PR #761 already merged and closed it — GitHub's auto-close had run but the lifecycle label hadn't been reconciled yet.

Source

Distillation for PR #761 (closing #745... #746), per the Curator's distill-lesson → promote-to-memory skills.

[danabaxia]

Merge conflict resolved: sibling-metric-noise-band-audit.md had diverging Evidence/Provenance sections (HEAD's PR #761 vs origin/main's PR #766, both independently gating precision's noise band and closing different duplicate issues). Combined both narratives to cover PR #758/#761/#766 and cross-linked [[close-duplicate-generated-issues]]. Full suite green (287/287 files). Not pushing — push is handled automatically after this step.

[github-actions]

Reviewer verdict: APPROVE — no blocking findings. (Posted as a comment, not a formal review: GitHub rejects gh pr review --approve here because this review session's identity matches the PR's own author — self-approval is blocked by GitHub itself, not a review decision. A human or differently-authenticated reviewer should convert this into the actual review state.)

Reviewed as a memory-only Curator promotion (no code touched): dev-mesh/curator/memory/workflows/sibling-metric-noise-band-audit.md.

Security/invariants: N/A — no code changed, so anti-spoof surface, no-Bash-in-do, single-writable-root/path-guard, AGENT.md-as-data, and fork-PR/workflow safety are all unaffected.

Correctness: cross-checked every cited issue (#742–#757) and PR (#758/#761/#766) against live GitHub state. The doc's core claims check out: first-run issues #742/#744/#746 (10:19:40Z) vs. second-run duplicates #752/#754/#756 (11:30:14Z) match actual creation timestamps, and the conclusion that #742/#754/#756 remain OPEN post-fix while #744/#746/#752 are CLOSED is accurate.

CI: validate-memory passes; other cells pass/in-progress with no failures. No test gap — nothing executable changed.

Optional (non-blocking) nit: step 5's lead-in sentence groups #742 among "duplicates filed by a second mesh-scan run," but #742 was actually filed by the first run per this same file's Evidence section a few lines down — a small internal inconsistency. The "(dup of #752)" pairing itself is fine (it follows the established convention in the sibling close-duplicate-generated-issues.md, pairing by which issue the fixing PR's Closes line referenced, not strict chronology). Worth a follow-up wording tweak, doesn't affect the actionable content.

[github-actions]

🤖 dev-mesh janitor: pushed an empty commit to nudge GitHub's mergeable recalc. If the state stays UNKNOWN after a few minutes, this PR likely needs a human.

[github-actions]

Reviewer verdict: REQUEST CHANGES (posted as a comment — gh pr review --request-changes failed: "Can not request changes on your own pull request". This PR's author is app/github-actions, the same identity this review job authenticates as via the default GITHUB_TOKEN, so GitHub rejects a formal review here. Flagging for a human/differently-credentialed reviewer to convert this into an actual review state — see note at the end.)

Review: PR #769

Scope: single file, memory-only (dev-mesh/curator/memory/workflows/sibling-metric-noise-band-audit.md). No code, no workflow, no invariant-relevant surface touched — security-review against PROJECT.md invariants (anti-spoof, no-Bash-in-do, single writable root/path-guard, AGENT.md-as-data, failure-is-data, fork-PR safety) is a clean pass: nothing in scope for any of them.

BLOCKING

Stale/now-false factual claim in the "new finding," contradicted by a sibling memory file already in the repo.

The new Step 5 + Evidence text asserts: "#742 … #754 … #756 … were never referenced anywhere and are still OPEN after the fix merged. They will stay open forever unless something explicitly closes them."

This is no longer true, and wasn't true even shortly after this PR was opened:

• [mesh-scan] perf-regression: precision regressed (-13.3%) #742 — CLOSED 2026-07-02T13:18:15Z (via merged PR [mesh-scan] perf-regression: precision regressed (-13.3%) (#742) #748)
• [mesh-scan] perf-regression: precision regressed (-13.3%) #754 — CLOSED 2026-07-02T13:18:12Z (via merged PR [mesh-scan] perf-regression: precision regressed (-13.3%) (#754) #770)
• [mesh-scan] perf-regression: precision regressed (-15%) #756 — CLOSED 2026-07-02T13:46:47Z (via merged PR [mesh-scan] perf-regression: precision regressed (-15%) (#756) #774)

All three were closed the same day, within roughly 30-90 minutes of this PR's createdAt (12:56:53Z). More importantly, this is already fully documented in the co-located, unmodified sibling memory file close-duplicate-generated-issues.md — which this very diff cross-links via [[close-duplicate-generated-issues]] — including an explicit "Correction: this is not actually a permanent leak" section stating the ledger's recoverRuns mechanism self-closes every sibling, and that #742/#746/#752/#754/#756 are all closed ("chain now fully closed").

Merging this PR as-is would bake a demonstrably false "will stay open forever" claim into a status: active memory file, directly contradicting its own cross-referenced sibling in the same directory. Since the entire value of this PR is the accuracy of the distilled lesson, this is a correctness bug, not a style nit — please update Step 5 / Evidence to reflect that #742/#754/#756 were subsequently closed (via #748/#770/#774), rather than re-asserting the "orphaned forever" framing, or drop the redundant claim in favor of deferring to close-duplicate-generated-issues.md's more complete and accurate account.

Non-blocking (optional)

• The stated second-scan-run timestamp (11:30:14Z) is a few minutes off from the actual issue createdAt values (~11:34:0x). Worth tightening if convenient, not worth a review cycle on its own.

Verdict

Requesting changes for the blocking item above (test coverage / spec-conformance / invariant scope are otherwise fine for a memory-only change).

---

Infra note for a human: the formal gh pr review --request-changes call errored because this job's GITHUB_TOKEN identity (github-actions[bot]) matches the PR's own author identity. If dev-mesh PRs are routinely opened under the same default token the review job uses, this will block a genuine review state on every such PR — worth giving the Reviewer job a distinct credential (e.g. a PAT) from whatever opens these PRs.