fieldtest: bundle friction/spec-gap findings into collective issues instead of one-per-finding #36

Closed
opened 2026-07-24 17:26:26 +02:00 by claude · 1 comment
Collaborator

Problem

The fieldtest skill's downstream routing files each finding as its own tracker
issue (bug → debug, friction → brainstorm/planner, spec_gap → ledger).
In practice a fieldtest yields 3–5 findings while a cycle closes 1–2 issues,
so the tracker grows structurally with every fieldtested cycle. Field evidence
from aura (2026-07-24): two consecutive cycles produced 10 routing issues;
the owner flagged the tracker growth, and a dedicated harvest sweep was needed
to drain the backlog (7 closures in one batch cycle, Brummel/Aura — see #35
data point 2 for the economics: ~81k tokens/closure in batch mode vs ~691k
for a single-issue full-pipeline cycle).

Practice change (ratified in aura, 2026-07-24 — proposal: encode it in the skill)

  1. Bundle findings. Related friction/spec_gap findings of one fieldtest
    go into ONE collective issue (or a comment on an existing open issue of the
    same line) instead of one issue per finding. Real bug findings keep
    individual issues — they are forward-queue work items; low-severity may wait
    in the collective issue.
  2. Consolidate before filing. Before creating any new issue, check whether
    an open issue of the same line can carry the scope (absorb + comment instead
    of a new issue).
  3. Periodic harvest sweeps. When small, settled, single-issue items
    accumulate, drain them as a batch cycle (settled issue bodies as spec
    source, sequential implementer batches of 2–3 items, one independent diff
    review over the whole sweep, one architect gate, one compact fieldtest).
    The independent review is not removable: in the aura sweep it caught the
    only substantive error, which came from orchestrator+fieldtest consensus,
    not from the implementers.

Where to encode

  • fieldtest/SKILL.md — the routing table under "Handoff Contract": make
    bundling the default for friction/spec_gap (collective issue or comment
    on an existing issue of the same line), keep per-issue routing for bug.
  • agents/fieldtester.md — no change to classification; the finding report
    stays per-finding. The bundling is an orchestrator-side routing rule.
  • Optionally docs/pipeline.md — name the harvest sweep as a recognized
    batch-cycle shape for draining settled single-issue backlog.

context: originated from the aura tracker-growth observation (owner,
2026-07-24); the practice is already applied in aura as a session rule and
should live in the skill so every project inherits it.

## Problem The fieldtest skill's downstream routing files each finding as its own tracker issue (`bug` → debug, `friction` → brainstorm/planner, `spec_gap` → ledger). In practice a fieldtest yields 3–5 findings while a cycle closes 1–2 issues, so the tracker grows structurally with every fieldtested cycle. Field evidence from aura (2026-07-24): two consecutive cycles produced 10 routing issues; the owner flagged the tracker growth, and a dedicated harvest sweep was needed to drain the backlog (7 closures in one batch cycle, Brummel/Aura — see #35 data point 2 for the economics: ~81k tokens/closure in batch mode vs ~691k for a single-issue full-pipeline cycle). ## Practice change (ratified in aura, 2026-07-24 — proposal: encode it in the skill) 1. **Bundle findings.** Related `friction`/`spec_gap` findings of one fieldtest go into ONE collective issue (or a comment on an existing open issue of the same line) instead of one issue per finding. Real `bug` findings keep individual issues — they are forward-queue work items; low-severity may wait in the collective issue. 2. **Consolidate before filing.** Before creating any new issue, check whether an open issue of the same line can carry the scope (absorb + comment instead of a new issue). 3. **Periodic harvest sweeps.** When small, settled, single-issue items accumulate, drain them as a batch cycle (settled issue bodies as spec source, sequential implementer batches of 2–3 items, one independent diff review over the whole sweep, one architect gate, one compact fieldtest). The independent review is not removable: in the aura sweep it caught the only substantive error, which came from orchestrator+fieldtest consensus, not from the implementers. ## Where to encode - `fieldtest/SKILL.md` — the routing table under "Handoff Contract": make bundling the default for `friction`/`spec_gap` (collective issue or comment on an existing issue of the same line), keep per-issue routing for `bug`. - `agents/fieldtester.md` — no change to classification; the finding report stays per-finding. The bundling is an orchestrator-side routing rule. - Optionally `docs/pipeline.md` — name the harvest sweep as a recognized batch-cycle shape for draining settled single-issue backlog. context: originated from the aura tracker-growth observation (owner, 2026-07-24); the practice is already applied in aura as a session rule and should live in the skill so every project inherits it.
claude added the feature label 2026-07-24 17:26:26 +02:00
claude self-assigned this 2026-07-24 20:15:39 +02:00
Author
Collaborator

Implemented in b2c92db. Encoding decisions taken along the way:

  1. Skip-rule registration went beyond the issue's "where to encode" list — pipeline.md's own rule ("skipping is codified per skill, not ad hoc") and specify's "no plan without an approved spec" invariant would otherwise contradict the new § Harvest sweep section. So the sweep is registered as the specify/planner exception in pipeline § Skip rules, in specify's named-alternatives list, in planner's skip list, and as a noun in conventions § Vocabulary.
  2. Whole-diff review executor: ad-hoc fresh-context dispatch. The per-task reviewer carriers cannot serve — quality-reviewer contractually requires a compliant spec-reviewer upstream, which a sweep (no plan, no task text) never has.
  3. Implementer step: direct implementer dispatches. The implement-loop carrier hard-requires a plan (standard) or RED test (mini); the sweep deliberately has neither. The dropped per-task review pair is stated explicitly, with the whole-diff review named as its replacement.
  4. Consolidate-before-filing stays fieldtest-side, faithful to the issue's "where to encode"; issue/SKILL.md itself carries no general consolidation rule.

Consciously NOT done (flagging rather than filing):

  • boss wiring — under /boss, queue selection (top-item + route cascade) never produces a sweep today; the new section only says the sweep is orchestrator-decided at queue selection. Wiring it into boss's Step 2 is a separate decision.
  • Glossary entry — the glossary takes only nomenclature already in consistent use; "harvest sweep" is first introduced by this commit. Candidate for a later maintain pass.
Implemented in b2c92db. Encoding decisions taken along the way: 1. **Skip-rule registration went beyond the issue's "where to encode" list** — pipeline.md's own rule ("skipping is codified per skill, not ad hoc") and specify's "no plan without an approved spec" invariant would otherwise contradict the new § Harvest sweep section. So the sweep is registered as the specify/planner exception in pipeline § Skip rules, in specify's named-alternatives list, in planner's skip list, and as a noun in conventions § Vocabulary. 2. **Whole-diff review executor: ad-hoc fresh-context dispatch.** The per-task reviewer carriers cannot serve — `quality-reviewer` contractually requires a `compliant` spec-reviewer upstream, which a sweep (no plan, no task text) never has. 3. **Implementer step: direct `implementer` dispatches.** The `implement-loop` carrier hard-requires a plan (standard) or RED test (mini); the sweep deliberately has neither. The dropped per-task review pair is stated explicitly, with the whole-diff review named as its replacement. 4. **Consolidate-before-filing stays fieldtest-side**, faithful to the issue's "where to encode"; `issue/SKILL.md` itself carries no general consolidation rule. Consciously NOT done (flagging rather than filing): - **boss wiring** — under `/boss`, queue selection (top-item + route cascade) never produces a sweep today; the new section only says the sweep is orchestrator-decided at queue selection. Wiring it into boss's Step 2 is a separate decision. - **Glossary entry** — the glossary takes only nomenclature already in consistent use; "harvest sweep" is first introduced by this commit. Candidate for a later maintain pass.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Brummel/Skills#36