[harness-experiment-proposal] issue-monster — context assembly/remove_redundant_context A/B harness experiment

### Summary

**Issue Monster** (`.github/workflows/issue-monster.md`) runs every 30 minutes — by far the highest-frequency workflow with zero active experiments in the current eligible set — and its main-agent prompt restates a "Scoring System" point-by-point breakdown that the pre-activation script has already computed and baked into the pre-fetched, pre-sorted issue list (each entry already carries `score: NN.N`). This proposes a `context assembly` / `remove_redundant_context` A/B experiment to trim that redundant paragraph.

### Observation

`issue-monster` has `run_count=2, success_count=2, failure_count=0, avg_aic=10.678, avg_action_minutes=10` over the current 14-day window (`per-workflow-summary.json`), and its frontmatter schedules it `every 30m` — the most frequent cadence of any zero-active-experiment candidate in `eligible-candidates.txt`, making it the strongest fit for reaching `min_samples: 20` per arm quickly. Its prompt (lines 601–613 pre-edit) restates a full per-label point breakdown ("Community: +60 points", "Good first issue: +50 points", ...) even though the pre-activation `github-script` step (lines 397–447) already computes each issue's final numeric score and prints it inline in `issue_list`/`issue_context` (e.g. `#123: Title [bug] (score: 45.0)`) — the agent is told explicitly to "work with this pre-fetched, filtered, and prioritized list... do not perform additional searches."

### Hypothesis

**Mechanism:** the per-label point-value breakdown is descriptive documentation of logic the deterministic pre-activation script already executed; the agent only needs to know issues are pre-sorted by priority and should act on the top of the list, not re-derive or double-check the scoring formula. Removing it shrinks the fixed prompt payload sent on every one of the ~48 runs/day this workflow fires, without touching the filtering/sorting behavior itself (unchanged, deterministic, in the pre-activation job).

**Expected direction:** decrease in `execution-duration` (ms).
**Minimum effect:** ≥5000 ms (5s) absolute decrease worth promoting for.

H0: No meaningful difference in execution-duration between control and candidate.
H1: Removing the redundant Scoring System breakdown decreases execution-duration without lowering the `issue_assigned` or `single_issue_scoped` eval pass rate.

### Candidate Mutation

- **primary_dimension:** `context assembly`
- **subtype:** `remove_redundant_context`
- **control:** unchanged — full "Scoring System" bullet list with all 10 point values kept in the prompt on every run.
- **candidate:** the bullet list is replaced with a single compact sentence ("Issues are already pre-scored and sorted by priority (community and good-first-issue candidates ranked highest) — prefer higher-scored issues from the list below."), removing ~12 lines of per-label point values that duplicate information already embedded in the pre-computed `score:` field shown for each issue.

This mirrors the same `context assembly`/`remove_redundant_context` subtype already running as A/B experiments on `daily-rendering-scripts-verifier` and `pr-sous-chef` (no `PROMOTE`/`REJECT` decision recorded for either yet — `experiments-analyses.jsonl` is currently empty — so this is an independent instance of the pattern, not an adaptation of a confirmed result).

### Experiment

```yaml
graders:
execution-duration: {}

experiments:
remove_redundant_context_v1:
variants: [control, candidate]
description: "Remove the 'Scoring System' point-breakdown paragraph from the main-agent prompt: the pre-activation script already computes each issue's final score and prints it inline in the pre-fetched issue list (e.g. 'score: 45.0'), so the per-label point values are redundant context the agent never needs to act on the already-sorted list."
hypothesis: "H0: No meaningful difference in execution-duration between control and candidate. H1: Removing the redundant Scoring System breakdown decreases execution-duration without lowering the issue_assigned or single_issue_scoped eval pass rate."
metric: "grader:execution-duration"
guardrail_metrics:
- name: "eval:issue_assigned"
threshold: ">=0.90"
- name: "eval:single_issue_scoped"
threshold: ">=0.90"
min_samples: 20
analysis_type: mann_whitney
decision:
minimum_effect: 5000
regression_tolerance: 5000
confidence: 0.95
tags: ["harness_dimension:context assembly", "harness_subtype:remove_redundant_context"]
```

No new `evals:` entries were needed — `issue_assigned` and `single_issue_scoped` are already declared in `issue-monster.md`'s frontmatter and are reused as guardrails.

### Guardrails

| Guardrail | Threshold | Why it protects against regression |
|---|---|---|
| `eval:issue_assigned` | `>=0.90` | Confirms the candidate still assigns at least one issue (or correctly no-ops) at the same rate — the trimmed prompt must not cause the agent to stall or misread the pre-sorted list. |
| `eval:single_issue_scoped` | `>=0.90` | Confirms the candidate still respects the "at most one issue per run" scoping rule — since `execution-duration` is a cost/efficiency `metric`, this guardrail (together with `issue_assigned`) protects correctness equivalence so a candidate cannot win purely by doing less work. |

### Expected Economics

`issue-monster` fires on a 30-minute schedule (`~48 runs/day`, subject to `skip-if-match`/`skip-if-no-match` gating), the highest cadence of any zero-active-experiment eligible candidate. Even accounting for skipped runs when no qualifying issues exist, `min_samples: 20` per arm (40 total assigned-variant runs) is realistic within roughly 1–3 weeks. Current baseline is `avg_action_minutes=10` (`per-workflow-summary.json`); the candidate mutation only removes ~12 lines (~100–150 tokens) of static prompt text, so the expected `execution-duration` delta is modest (on the order of single-digit seconds) — consistent with the `minimum_effect`/`regression_tolerance` of 5000 ms chosen above.

### Validation

`./gh-aw compile issue-monster --strict` and `./gh-aw compile issue-monster --strict --validate` both exited `0` (only warnings: `Using experimental feature: graders`, `Using experimental feature: gh-aw-detection` — both pre-existing/expected for this workflow). `git diff --stat` after compiling touched only `.github/workflows/issue-monster.md` and `.github/workflows/issue-monster.lock.yml`; the compiled lock file contains the new `remove_redundant_context_v1` experiment name and templated `GH_AW_EXPERIMENT_SPEC` wiring, confirming the block was accepted. The working tree was reverted after validation (this workflow has no write authority).

### Interpretation

Applying this patch only **starts** the experiment; no decision is interpreted here. Once `min_samples` is reached, `gh aw experiments analyze issue-monster` computes the deterministic `EXTEND`/`PROMOTE`/`REJECT`/`INCONCLUSIVE` decision unchanged — this workflow never recomputes, reinterprets, or overrides that decision, and any eventual `PROMOTE` still requires a separate, human-reviewed change through the existing `daily-experiment-report` deterministic decision engine. This workflow never merges anything itself.

### Rollback

Revert the commit that applies this patch (`git revert `), then recompile with `gh aw compile issue-monster --strict --validate`. No other files depend on this change — the `graders:`/`experiments:` blocks and the single templated conditional are fully self-contained within `issue-monster.md`.

### Manual Patch (apply by hand)

```diff
diff --git a/.github/workflows/issue-monster.md b/.github/workflows/issue-monster.md
index bad6ef0..b1b9821 100644
--- a/.github/workflows/issue-monster.md
+++ b/.github/workflows/issue-monster.md
@@ -510,6 +510,28 @@ permissions:
features:
gh-aw-detection: true

+graders:
+ execution-duration: {}
+
+experiments:
+ remove_redundant_context_v1:
+ variants: [control, candidate]
+ description: "Remove the 'Scoring System' point-breakdown paragraph from the main-agent prompt: the pre-activation script already computes each issue's final score and prints it inline in the pre-fetched issue list (e.g. 'score: 45.0'), so the per-label point values are redundant context the agent never needs to act on the already-sorted list."
+ hypothesis: "H0: No meaningful difference in execution-duration between control and candidate. H1: Removing the redundant Scoring System breakdown decreases execution-duration without lowering the issue_assigned or single_issue_scoped eval pass rate."
+ metric: "grader:execution-duration"
+ guardrail_metrics:
+ - name: "eval:issue_assigned"
+ threshold: ">=0.90"
+ - name: "eval:single_issue_scoped"
+ threshold: ">=0.90"
+ min_samples: 20
+ analysis_type: mann_whitney
+ decision:
+ minimum_effect: 5000
+ regression_tolerance: 5000
+ confidence: 0.95
+ tags: ["harness_dimension:context assembly", "harness_subtype:remove_redundant_context"]
+
model: copilot/gpt-5.4
engine: pi
imports:
@@ -599,6 +621,9 @@ The issue search has already been performed in the pre-activation job with smart
- 🛑 Excluded **retry-blocked topics**: issues whose normalized title matches two or more Copilot PRs that were closed without merging
- ✅ Prioritized issues with labels: good-first-issue, bug, security, documentation, enhancement, feature, performance, tech-debt, refactoring

+{{#if experiments.remove_redundant_context_v1 == 'candidate' }}
+**Scoring System:** Issues are already pre-scored and sorted by priority (community and good-first-issue candidates ranked highest) — prefer higher-scored issues from the list below.
+{{#else}}
**Scoring System:**
Issues are scored and sorted by priority:
- **Community**: +60 points *(always highest — issues from external contributors)*
@@ -611,6 +636,7 @@ Issues are scored and sorted by priority:
- Tech-debt/Refactoring: +20 points
- Has any priority label: +10 points
- Age bonus: +0-20 points (older issues get slight priority)
+{{#endif}}

**Issue Count**: ${{ needs.pre_activation.outputs.issue_count }}
**Issue Numbers**: ${{ needs.pre_activation.outputs.issue_numbers }}
```

### Application Plan

1. Save the diff above as `proposal.patch`.
2. `git apply proposal.patch`
3. `gh aw compile issue-monster --strict --validate`
4. Open a PR manually if compilation succeeds.

> [!WARNING]
>
> Firewall blocked 1 domain
>
> The following domain was blocked by the firewall during workflow execution:
>
> - `api.anthropic.com`
>
> To allow these domains, add them to the `network.allowed` list in your workflow frontmatter:
>
> ```yaml
> network:
> allowed:
> - defaults
> - "api.anthropic.com"
> ```
>
> See [Network Configuration](https://github.github.com/gh-aw/reference/network/) for more information.
>
>

> Generated by [🧫 Daily Harness Experiment Proposer](https://github.com/github/gh-aw/actions/runs/34947866695) · claude · agent · 186.9 AIC · ⊞ 15.5K · [◷](https://github.com/search?q=repo%3Agithub%2Fgh-aw+is%3Aissue+%22gh-aw-workflow-call-id%3A+github%2Fgh-aw%2Fdaily-harness-experiment-proposer%22&type=issues)
> - [x] expires on Sep 22, 2026, 12:51 AM UTC-08:00

Start in .github/workflows/issue-monster.md, reading the pre-activation github-script step around lines 397–447 and the main-agent prompt around lines 601–613. Apply the proposed experiment configuration and conditional prompt text, then run `gh aw compile issue-monster --strict --validate`. Done means compilation succeeds and the generated changes are limited to issue-monster.md and its lock file.

Written by the indexing model from the issue text.