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>
187 lines
6.1 KiB
Markdown
187 lines
6.1 KiB
Markdown
---
|
|
type: trekbrief
|
|
brief_version: "2.2"
|
|
created: {YYYY-MM-DD}
|
|
task: "{one-line task description}"
|
|
slug: {slug}
|
|
project_dir: .claude/projects/{YYYY-MM-DD}-{slug}/
|
|
research_topics: {N}
|
|
research_status: pending # pending | in_progress | complete | skipped
|
|
auto_research: false # true if user opted into Claude-managed research
|
|
interview_turns: {N}
|
|
source: {interview | manual}
|
|
# v5.5 — framing: how this brief relates to prior operator intent. REQUIRED at
|
|
# brief_version ≥ 2.2. One of: preserve | refine | replace | new-direction.
|
|
# AskUserQuestion-validated in /trekbrief Phase 2.5 BEFORE any brief prose is
|
|
# written — the first layer of the framing-alignment defense (guards against the
|
|
# plan polishing a wrong premise after a rejected iteration).
|
|
framing: {preserve | refine | replace | new-direction}
|
|
# v5.1 — per-phase effort + model signal (Phase 3.5).
|
|
# `effort` ∈ {low, standard, high}; `model` ∈ {sonnet, opus, fable} (v5.9).
|
|
# Omit `model:` for `standard` so composition falls through to profile
|
|
# resolver. Force-stop alternative is the commented
|
|
# `phase_signals_partial: true` below (mutually exclusive with `phase_signals`).
|
|
phase_signals:
|
|
- phase: research
|
|
effort: standard
|
|
- phase: plan
|
|
effort: standard
|
|
- phase: execute
|
|
effort: standard
|
|
- phase: review
|
|
effort: standard
|
|
# phase_signals_partial: true # uncomment to record force-stop instead of phase_signals
|
|
---
|
|
|
|
# Task: {title}
|
|
|
|
> Generated by `/trekbrief` on {YYYY-MM-DD}.
|
|
> This brief is the contract between requirements and planning. `/trekplan`
|
|
> reads 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 test` exits 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 --noEmit` exits 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):
|
|
|
|
```bash
|
|
# 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.
|