fix(analyst-loop): forward same-run findings

[drewstone]

Summary

• expose agent-eval's opt-in same-run finding chain through runAnalystLoop
• preserve independent analysts by default
• document registration-order behavior and verify it with the real Eval registry

Verification

• focused tests: 19 passed
• full tests: 1,859 passed; 6 skipped
• lint, typecheck, docs check, and package verification passed

[tangletools]

✅ Auto-approved drewstone PR — 5944cb23

This PR was opened by the trusted drewstone account.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.

_{tangletools · auto-approval · reason: drewstone_author · 2026-07-29T20:08:17Z}

[tangletools]

🟢 Value Audit — sound

Verdict	sound
Concerns	0 (none)
Heuristic	0.0s
Duplication	0.0s
Interrogation	102.0s (2 bridge agents)
Total	102.0s

💰 Value — sound

Forwards agent-eval's existing opt-in same-run finding-chain option through runAnalystLoop, which was previously swallowing it; clean, minimal, defaults to off, tested against the real registry.

• What it does: Exposes the chainFindings?: boolean option on RunAnalystLoopOpts and threads it into the registryOptions object passed to registry.run/registry.runStream. When on, the underlying AnalystRegistry populates each later analyst's ctx.upstreamFindings with findings emitted by earlier analysts in the same run (registration order = dependency order). When off (the default), behavior is unch
• Goals it achieves: Close a real gap: the orchestrator was constructing the registry options object internally and silently dropping chainFindings, so callers had no way to turn on same-run finding chaining through runAnalystLoop even though the underlying registry fully supported it (agent-eval accumulates findings in registration order and populates ctx.upstreamFindings when the flag is set, with dedicated `r
• Assessment: Good change. It is a minimal, correct forwarding that matches the exact established grain in the same object literal (...(opts.x ? { x: opts.x } : {})), defaults to off to preserve existing behavior, and adds the option to the narrowed registry type shapes so the typed contract stays honest. The two new tests use the REAL AnalystRegistry (not the stub) to prove both the on-path (second analyst
• Better / existing approach: none — this is the right approach. Verified chainFindings/upstreamFindings is the real, mature capability in agent-eval (default-registry-Brxr728w.d.ts:230 RegistryRunOpts.chainFindings; default-registry-CHmdy2An.js:2088 populates ctx.upstreamFindings from an accumulating allFindings array; renderUpstreamFindings exists at d.ts:139). There is no pre-existing passthrough in runAnalystLoop — it
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 2
• Bridge warning: opencode/kimi-for-coding/k2p7: bridge stream ended without value-audit content

🎯 Usefulness — sound

A minimal, opt-in pass-through that exposes agent-eval's native same-run finding chain through the orchestrator, tested against the real registry — coherent, non-competing, and reachable.

• Integration: Reachable and correctly wired. run-analyst-loop.ts:148 forwards opts.chainFindings into the curated registryOptions object alongside priorFindings/costLedger/signal, using the same conditional-spread idiom. The underlying agent-eval AnalystRegistry natively consumes chainFindings and populates ctx.upstreamFindings (confirmed in node_modules/@tangle-network/agent-eval/dist/default-registry-Brxr728w
• Fit with existing patterns: Fits the grain precisely. It mirrors the established forwarding pattern for the sibling priorFindings option and the other curated registry opts; the orchestrator deliberately curates which fields cross into the registry rather than blanket-spreading (since RunAnalystLoopOpts carries loop-only fields like findingsStore/baselineRunId that must not reach the registry), and this change respects that
• Real-world viability: Holds up because the orchestrator's role here is pure pass-through; the hard parts (sequential/dependency-ordered execution, populating upstreamFindings, handling a failed earlier analyst) are owned by the agent-eval registry, an established component. The flag defaults off, so every existing analyst suite keeps identical behavior — zero regression surface. The forwarding guard `opts.chainFindings
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 1

No concerns — sound change, no better or existing approach found. ✅

---

What this audit checks

It judges the change on its merits — not whether it was tasked out in an issue. Unticketed, fast-moving work is fine; the question is whether the change is good and whether a better or existing approach should be used instead.

Pass	What it asks
Heuristic	Vague title? Whitespace-only or cruft-bearing diff? (content signals only)
Duplication	Do added function/class names already exist elsewhere in the repo?
Value Audit	What does it do? What goal does it achieve? Is it good? Better architecture or already-exists?
Usefulness Audit	Does it integrate and fit? Will it hold up in real use and actually get used?

Findings are concerns, not blocks — the human reviewer decides what to do with them.

_{value-audit · 20260729T201019Z}

[tangletools]

✅ No Blockers — 5944cb23

Review health 100/100 · Reviewer score 86/100 · Confidence 80/100 · 3 findings (3 low)

glm: Correctness 86 · Security 86 · Testing 86 · Architecture 86

Reviewer score is advisory once the run is complete and the verdict has no blockers.

Full multi-shot audit completed 4/4 planned shots over 6 changed files. Global verifier still owns final merge decision.

🟡 LOW opts prose example omits the newly-documented chainFindings — docs/api/runtime.md

The prose for RegistryAnalyzeProjection.opts still reads 'Optional run opts (e.g. priorFindings) forwarded verbatim to the registry.' even though this same opts object now also carries the newly added chainFindings. The type is correct (it is Parameters<AnalystRegistryLike['run']>[2], which includes both), so this is cosmetic only — but for discoverability the example could read 'e.g. priorFindings, chainFindings'. No behavioral impact.

🟡 LOW Chaining not exercised through the streaming (runStream) path — tests/analyst-loop.test.ts

captureSameRunUpstreamFindings does not pass onEvent, so runRegistry takes the registry.run() branch (run-analyst-loop.ts:153 requires both runStream AND onEvent). The chainFindings flag is built into the same registryOptions object for both branches (run-analyst-loop.ts:146-152), so the gap is low-risk, but the streaming+chaining combination is untested. Consider adding onEvent to one chaining case to cover the runStream forwarding path. Not a blocker.

🟡 LOW Explicit chainFindings:false case not tested — tests/analyst-loop.test.ts

The 'isolated' test passes chainFindings as undefined. The loop forwards chainFindings only when !== undefined (run-analyst-loop.ts:148), so explicit false would also be forwarded to the registry — but that explicit-false path is not asserted. Minor coverage gap; the undefined default is the more important case and is covered.

---

_{tangletools · 2026-07-29T20:13:24Z · trace}

[tangletools]

✅ Approved — 3 non-blocking findings — 5944cb23

Full multi-shot audit completed 4/4 planned shots over 6 changed files. Global verifier still owns final merge decision.

Full immutable report for this review: trace

Summary comment for this run: full summary

---

_{tangletools · 2026-07-29T20:13:24Z · immutable trace}

[tangletools]

✅ Auto-approved drewstone PR — cede720b

This PR was opened by the trusted drewstone account.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.

_{tangletools · auto-approval · reason: drewstone_author · 2026-07-30T07:27:58Z}

[tangletools]

🟢 Value Audit — sound

Verdict	sound
Concerns	0 (none)
Heuristic	0.0s
Duplication	0.0s
Interrogation	101.0s (2 bridge agents)
Total	101.0s

💰 Value — sound

Exposes agent-eval's existing same-run finding-chain opt through runAnalystLoop; minimal, in-grain, backward-compatible by default, tested against the real registry.

• What it does: Adds an opt-in chainFindings?: boolean to RunAnalystLoopOpts and forwards it into the registry's run opts (both the run and runStream paths) in run-analyst-loop.ts:148. When on, the underlying agent-eval AnalystRegistry populates ctx.upstreamFindings for each later analyst with findings produced earlier in the same registry run. Also threads the field through the AnalystRegistryLike
• Goals it achieves: Lets a multi-analyst suite build a same-run dependency chain (analyst B reasons over analyst A's diagnosis from the current run) instead of only seeing prior-run findings. Registration order becomes dependency order when enabled. Keeps cross-run priorFindings and same-run chainFindings cleanly separated, and preserves today's independent-analyst behavior by defaulting to off.
• Assessment: Good change on its merits. The capability already exists end-to-end in agent-eval (verified in dist/default-registry-Brxr728w.d.ts:225-230 and dist/types-DVjczBM9.d.ts:135-137 of agent-eval@0.135.1: RegistryRunOpts.chainFindings populates AnalystContext.upstreamFindings); this PR only stops the orchestrator from dropping that option. The forwarding follows the exact established pattern already
• Better / existing approach: none — this is the right approach. Searched src/ and tests/ for any pre-existing same-run chaining in agent-runtime (grep chainFindings|upstreamFindings): the only hits are this PR. The orchestrator already had cross-run priorFindings + priorFindingsStrategy (per-kind/wildcard/none) at run-analyst-loop.ts:54 and types.ts:77, but that is a distinct concept (prior-run context), and the two are
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 2
• Bridge warning: opencode/kimi-for-coding/k2p7: bridge stream ended without value-audit content

🎯 Usefulness — sound

A minimal, default-off pass-through exposing agent-eval's same-run finding chain through the canonical analyst loop, wired exactly like the existing priorFindings/costLedger forwards and reachable by both real consumers.

• Integration: Correctly wired and reachable. runRegistry forwards opts.chainFindings into registryOptions (run-analyst-loop.ts:148) using the same conditional-spread idiom as priorFindings/costLedger/costPhase/signal (lines 147-152). The underlying capability is real: agent-eval 0.135.2 — the exact pnpm-workspace catalog version — defines RegistryRunOpts.chainFindings and populates ctx.upstreamFindings (verifie
• Fit with existing patterns: Fits the established grain precisely. It is the same-run analog of priorFindings (cross-run): both are registry opts forwarded by runRegistry, both default-off, both surfaced via ctx. agent-eval itself documents the pairing ('For findings from this run, use chainFindings instead' next to priorFindings). Default-off preserves independent-analyst suites' current behavior, matching the codebase's opt
• Real-world viability: Holds up beyond the happy path. The forwarding is a single field added to an object literal — no new control flow, no new error paths; registry failures propagate exactly as before. Default-off and explicit-false are both tested, and the streaming path is tested with the real AnalystRegistry (tests/analyst-loop.test.ts:227-258). The one caller responsibility — that registration order is meaningful
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 1

No concerns — sound change, no better or existing approach found. ✅

---

What this audit checks

It judges the change on its merits — not whether it was tasked out in an issue. Unticketed, fast-moving work is fine; the question is whether the change is good and whether a better or existing approach should be used instead.

Pass	What it asks
Heuristic	Vague title? Whitespace-only or cruft-bearing diff? (content signals only)
Duplication	Do added function/class names already exist elsewhere in the repo?
Value Audit	What does it do? What goal does it achieve? Is it good? Better architecture or already-exists?
Usefulness Audit	Does it integrate and fit? Will it hold up in real use and actually get used?

Findings are concerns, not blocks — the human reviewer decides what to do with them.

_{value-audit · 20260730T072957Z}

[tangletools]

✅ No Blockers — cede720b

Review health 100/100 · Reviewer score 89/100 · Confidence 85/100 · 2 findings (2 low)

glm: Correctness 89 · Security 89 · Testing 89 · Architecture 89

Reviewer score is advisory once the run is complete and the verdict has no blockers.

Full multi-shot audit completed 5/5 planned shots over 7 changed files. Global verifier still owns final merge decision.

🟡 LOW Forwarding an explicit chainFindings:false is a documented no-op — src/analyst-loop/run-analyst-loop.ts

The !== undefined guard preserves an explicit false, which the test 'forwards an explicit false chain setting' asserts. This is intentional and harmless, but note the registry reads runOpts.chainFindings && allFindings.length > 0 (agent-eval registry.ts:293), so false and omitted produce byte-identical behavior (both yield upstreamFindings: undefined). No change required — flagged only so reviewers know the explicit-false round-trip conveys caller intent, not distinct semantics. Not blocking.

🟡 LOW Weak event-count assertion in streaming chaining test — tests/analyst-loop.test.ts

The streaming-path chaining test asserts only expect(emittedEvents).toBeGreaterThan(0) rather than verifying event types or ordering. This is a smoke check that would pass even if the loop emitted a single spurious event. The existing 'runAnalystLoop onEvent' describe block covers event ordering for non-chaining runs, but no test asserts the streaming chaining path emits the expected baseline-resolved -> analyst(run-started) -> analyst(analyst-completed) -> loop-completed sequence. Low severity because the behavioral assertion (seen includes first-finding) is the load-bearing claim; the event count is secondary.

---

_{tangletools · 2026-07-30T07:36:53Z · trace}

[tangletools]

✅ Approved — 2 non-blocking findings — cede720b

Full multi-shot audit completed 5/5 planned shots over 7 changed files. Global verifier still owns final merge decision.

Full immutable report for this review: trace

Summary comment for this run: full summary

---

_{tangletools · 2026-07-30T07:36:53Z · immutable trace}