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>
6.1 KiB
| type | brief_version | created | task | slug | project_dir | research_topics | research_status | auto_research | interview_turns | source | framing | phase_signals | ||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| trekbrief | 2.2 |
|
{one-line task description} |
|
.claude/projects/{YYYY-MM-DD}-{slug}/ |
|
pending | false |
|
|
|
|
Task: {title}
Generated by
/trekbriefon {YYYY-MM-DD}. This brief is the contract between requirements and planning./trekplanreads it to produce the implementation plan. Every decision in the plan must trace back to content in this brief.
TL;DR
≤ 5 lines. The framing-anchored one-glance summary: what this brief asks for and how it relates to prior operator intent (framing: {preserve | refine | replace | new-direction}). Written FIRST so a reader catches a wrong premise before reading the full brief. Required at brief_version ≥ 2.2.
{≤5-line summary.}
Intent
Why are we doing this? What is the motivation, user need, or strategic context? 3-5 sentences. Load-bearing for the plan — every implementation decision must trace back to this intent.
{Intent paragraph. Answers "why bother?".}
Goal
What does success look like concretely? What state will the system be in when this is done? 1 paragraph. Specific enough to disagree with.
{Goal paragraph.}
Non-Goals
What is explicitly out of scope? Prevents plan-critic and scope-guardian from flagging gaps for things we deliberately do not do.
- {non-goal 1}
- {non-goal 2}
Constraints
Technical, time, or resource limitations. Hard boundaries the plan must respect.
- {constraint 1}
- {constraint 2}
Preferences
Preferred patterns, frameworks, libraries, or approaches. Soft constraints (the plan may deviate with justification).
- {preference 1}
- {preference 2}
Non-Functional Requirements
Performance, security, accessibility, scalability, or other quality attributes. Quantified where possible.
- {NFR 1 — e.g., "p95 response time < 200ms"}
- {NFR 2 — e.g., "Zero new npm dependencies"}
Success Criteria
Falsifiable, command-checkable conditions that define "done". Each must be verifiable by running a specific command or observing a specific system behavior.
- {criterion — e.g., "All existing tests pass:
npm testexits 0"} - {criterion — e.g., "New endpoint returns 200:
curl -s localhost:3000/api/health | jq .status→"ok""} - {criterion — e.g., "No TypeScript errors:
npx tsc --noEmitexits 0"}
Do NOT write vague criteria:
- "It should work" (not testable)
- "The feature is implemented" (not falsifiable)
- "Performance is acceptable" (no baseline given)
Research Plan
Explicit research topics that must be answered before /trekplan can
produce a high-confidence plan. Each topic is phrased as a research question ready
to feed into /trekresearch. Topics may be empty (N=0) for trivial tasks
where the codebase alone is sufficient context.
{If research_topics = 0, write a single line: "No external research needed — the codebase and this brief contain sufficient context for planning."}
Topic 1: {Short title}
- Why this matters: {How the plan depends on this answer. Which steps or decisions cannot be made confidently without it.}
- Research question: "{Exact question to feed to /trekresearch.
One sentence, ends in
?.}" - Suggested invocation:
/trekresearch --project {project_dir} --external "{question}" - Required for plan steps: {which kinds of steps will consume this — e.g., "migration strategy", "library selection", "threat model"}
- Confidence needed: {high | medium | low}
- Estimated cost: {quick — inline research | standard — agent swarm | deep — with contrarian}
- Scope hint: {local | external | both}
Topic 2: {Short title}
- Why this matters: ...
- Research question: "..."
- Suggested invocation:
/trekresearch --project {project_dir} ... - Required for plan steps: ...
- Confidence needed: ...
- Estimated cost: ...
- Scope hint: ...
Open Questions / Assumptions
Things still uncertain after the interview. These are carried as [ASSUMPTION]
entries into the plan and flagged to the user for review.
- {question or assumption 1}
- {question or assumption 2}
Prior Attempts
What has been tried before and what happened. Leave blank for fresh tasks. Prior attempts are load-bearing — they prevent the plan from repeating known failures.
{Prior attempts narrative, or "None — fresh task."}
Metadata
- Created: {YYYY-MM-DD}
- Interview turns: {N}
- Auto-research opted in: {yes | no}
- Source: {trekbrief interview | manual}
How to continue
Manual (default):
# Run each research topic (order does not matter):
/trekresearch --project {project_dir} --external "{Topic 1 question}"
/trekresearch --project {project_dir} --external "{Topic 2 question}"
# Then plan:
/trekplan --project {project_dir}
# Then execute:
/trekexecute --project {project_dir}
Auto (opt-in during /trekbrief): research and planning run
automatically; only execution is manual.