Kjell Tore Guttormsen 1ca48e0cd0 release(v5.10.1): drop gemini-bridge from the pipeline; correct the T1 §6 PoC status

gemini-bridge is dropped by operator directive (three repetitions). The drop is
permanent, not a wait-for-SDK-upgrade state, so the change clears every LIVE
surface that could still steer a run toward the agent and leaves the historical
record alone.

Live surfaces cleared: agents/gemini-bridge.md deleted; trekresearch (bridge
launch block, --local help, high-effort always-on pair, stats record,
degradation list), trekplan, trekbrief, research-orchestrator (mode table,
agent table, prompting block, summary line), README (feature prose, mode table,
agent prose, mermaid EXTERNAL node, conditional legend, optional-MCP
requirement, --local section), CLAUDE.md, settings.json (the whole
trekresearch.geminiBridge block), both templates, architecture.md,
command-modes.md.

trekplan high-effort Adversarial Pass 2 now degrades EXPLICITLY: it emits its
section with status "unavailable, skipped" instead of failing or vanishing. A
high-effort plan carrying no Pass 2 marker is indistinguishable from one whose
Pass 2 crashed, which is the failure mode this wording exists to prevent.

gemini_used is deliberately KEPT as a vestigial trekresearch stats field pinned
to false. Removing it would break the observability export schema for existing
consumers, and the directive was about the agent, not the field.

Not touched: CHANGELOG history and the measurement/decision docs keep their
gemini references. They record what a past version did or what was measured
then; rewriting them is the same defect class as bumping a version string
inside a measurement doc.

Driven test-first. Five new pins in tests/lib/doc-consistency.test.mjs, verified
RED before the edits, including a KNOWN-POSITIVE CONTROL asserting the
historical records still DO carry gemini references — so the empty result on
live surfaces is a measurement and not a broken query (Verifiseringsloven
ansikt 4). Agent inventory 24 -> 23 (20 spawnable + 3 orchestrator reference
docs); the <example>-block floor moves 34 -> 32 because an agent legitimately
left the inventory, not because examples went missing from a surviving one.

Docs: docs/T1-cc26-delegated-orchestration.md §8 item 3 claimed both the §6
synthesis-agent PoC and the §5 bake-off were "designed but unbuilt". That was
written in S7 and falsified the same afternoon by S12, which ran the §6 PoC and
recorded Δ main-context (faithful flow) = 0.0%, NEGATIVE. The stale wording is
what caused the settled PoC to be re-ordered as new work on 2026-09-02, so it is
struck rather than deleted and §6 gained a RUN AND DECLINED status block. The
finding is structural, not stochastic: Phase 5 spawns the exploration swarm
foreground (trekplan.md:158,338-341), so the outputs are already resident in
main before Phase 7 — delegating only the Phase-7 digest evicts nothing.

Also measured 2026-09-03 (CC 2.1.259): claude -p --output-format stream-json
runs on subscription auth with no ANTHROPIC_API_KEY and now emits a
subagent_stats block, so S12's environment-block premise is half stale. Recorded
in §8 item 4. It lowers the cost of §5; it changes nothing about §6.

Suite 1041 (1039/0/2), up from 1036 by exactly the five tests added.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-09-03 20:29:39 +02:00

3.4 KiB

Raw Blame History

type

created

question

confidence

dimensions

mcp_servers_used

local_agents_used

external_agents_used

trekresearch-brief

YYYY-MM-DD

{research question}

0.0-1.0

N

list

list

list

{Research Question Title}

Generated by trekresearch v{version} on {YYYY-MM-DD}

Research Question

{The full research question as clarified during interview.}

Executive Summary

{3 sentences maximum. The answer, the confidence level, and the key caveat.}

Dimensions

Each dimension represents one facet of the research question, explored by both local and external agents. Confidence is rated per dimension.

{Dimension Name} -- Confidence: {high | medium | low | contradictory}

Local findings:

{Finding with source citation (file path or agent name)}

External findings:

{Finding with source citation (URL)}

Contradictions:

{If local and external disagree, explain both sides with evidence. Omit this sub-section if no contradictions exist for this dimension.}

Repeat for each dimension.

Local Context

Findings from codebase analysis agents. Omit sub-sections where no relevant findings exist.

Architecture

{Architecture patterns, tech stack, relevant components from architecture-mapper}

Dependencies

{Import chains, data flow, external integrations from dependency-tracer}

Conventions

{Coding patterns, naming, test conventions from convention-scanner}

History

{Recent changes, code ownership, hot files from git-historian}

External Knowledge

Findings from external research agents. Omit sub-sections where no relevant findings exist.

Best Practice

{Official documentation, recommended patterns from docs-researcher}

Alternatives

{Other approaches, competing solutions from community-researcher + contrarian-researcher}

Security

{CVEs, audit history, supply chain risks from security-researcher}

Known Issues

{Common pitfalls, gotchas, real-world problems from community-researcher}

Synthesis

Cross-cutting insights that emerge from combining local and external knowledge. This is NOT a summary of the sections above. It is NEW insight from triangulation -- things that only become visible when local context meets external knowledge.

{Example: "The codebase uses pattern X (local), but best practice has shifted to pattern Y (external). However, our dependency on Z (local) makes a direct migration impractical -- a hybrid approach using Y for new code while maintaining X for existing modules is the pragmatic path."}

Open Questions

Things that remain unresolved after research. Each is a candidate for follow-up research or an assumption to carry forward.

{Question 1 -- why it remains open}
{Question 2 -- why it remains open}

Recommendation

If the research was decision-relevant, provide a concrete recommendation with reasoning. If the research was exploratory (understanding, not deciding), omit this section entirely.

{Recommendation with rationale, citing specific findings from above.}

Sources

#	Source	Type	Quality	Used in
1	{URL or codebase path}	{official / community / codebase}	{high / medium / low}	{dimension name}

Quality assessment:

high — official documentation, verified codebase analysis, peer-reviewed
medium — reputable community source, well-maintained blog, established project
low — unverified, outdated (>1 year), single-source claim, opinion piece

3.4 KiB Raw Blame History