Kjell Tore Guttormsen
1ca48e0cd0
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>
113 lines
3.4 KiB
Markdown
113 lines
3.4 KiB
Markdown
---
|
|
type: trekresearch-brief
|
|
created: {YYYY-MM-DD}
|
|
question: "{research question}"
|
|
confidence: {0.0-1.0}
|
|
dimensions: {N}
|
|
mcp_servers_used: [{list}]
|
|
local_agents_used: [{list}]
|
|
external_agents_used: [{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
|