/reproduce-and-fix-issues

name: reproduce-and-fix-issues
description: Reproduce triaged Slack bugs through a configured app-control adapter, verify existing fixes, and open a bounded draft pull request only after before-and-after proof. Use only from the configured Benny repro automation.
disable-model-invocation: true

Reproduce and fix issues

Wait for a trusted triage marker in the source thread. Reproduce the exact symptom through the target app's real UI. Verify an existing fix when one exists. Attempt a bounded fix only after a confirmed repro.

Load the external Benny configuration supplied by the automation. If the config, required actions, control adapter, or completed feature map is missing, fail closed.

Hard safety rules

• Freeze the source channel and root thread coordinates before doing any work.
• Never post a root message in the source channel.
• Preflight the source parent before every source-thread post.
• The coordinator is the only Slack poster.
• Delegated analysis workers are read-only and return findings or media notes.
• A fix-phase code worker may edit only when its environment provably excludes Slack credentials and every Slack write action. Otherwise the coordinator edits.
• Every child prompt must explicitly forbid `SendSlackMessage`, `PostToSlack`, `chat.postMessage`, and all other Slack writes.
• Never give a child a Slack token, posting instructions, source coordinates for posting, or permission to report externally.
• If a child needs Slack write access to run, do not launch it.
• Utility bots are evidence sources. They do not own the fix unless a person explicitly delegated the fix to them.
• The exact discriminating symptom must appear twice through real UI interaction.
• State inspection may confirm an observation. It must not inject or force the symptom.
• No confirmed repro means no authored fix.
• Existing pull requests or commits switch the run to verify mode. Do not author over them.
• Use `github.com` pull request links.
• Keep captures, recordings, logs, and tokens out of source control.
• Use pstack's `principle-guard-the-context-window` for delegated analysis.
• Apply pstack's `principle-sequence-verifiable-units`, `principle-fix-root-causes`, and `principle-prove-it-works` through repro, fix, and verification.

1. Freeze source coordinates

Before making a work list or delegating:

1. Require the trigger channel to equal the configured source channel. 2. Set `SOURCE_THREAD_TS` to `trigger.thread_ts` when present. Otherwise use `trigger.ts`. 3. Require a nonempty `SOURCE_THREAD_TS`. 4. Store `SOURCE_CHANNEL_ID` and `SOURCE_THREAD_TS` as immutable values. 5. Read the source thread and verify its root has those exact coordinates. 6. Fetch the source permalink.

Never replace these values with a reply timestamp, operations timestamp, or status-message timestamp.

Before every source-channel post:

1. Read the thread by the immutable coordinates. 2. Confirm the parent exists, is not deleted, and still belongs to the source channel. 3. Send only with `channel=SOURCE_CHANNEL_ID` and `thread_ts=SOURCE_THREAD_TS`. 4. Read the thread again and verify the new message is a reply.

If any check fails, post nothing. Never retry at the root or in a fallback channel.

2. Wait for the triage contract

Watch the source thread for the configured verdict budget. Stay silent while waiting.

Accept a verdict only when:

• Its author matches `slack.triage_identity_user_id`.
• It is a reply under `SOURCE_THREAD_TS`.
• It contains exactly one configured marker.

Public marker forms:

[benny:bug]
[benny:bug] tracker=https://tracker.example/issue/123
[benny:performance]
[benny:performance] tracker=https://tracker.example/issue/123
[benny:other]

Proceed only for `bug` or `performance`. Capture the optional tracker URL. Stop silently for `other`, a missing verdict, an untrusted author, conflicting markers, or a timeout.

This marker replaces private bot identities and free-form verdict matching.

3. Apply ownership and fix-artifact gates

Re-read the thread immediately before starting work.

Someone is explicitly fixing it

Stop when a person clearly claims the fix, gives a concrete implementation plan, or asks another agent to implement, patch, fix, or open a pull request.

Do not treat these as fix ownership:

• A bot summarizes evidence.
• A tool looks up logs or tickets.
• Someone asks a bot to diagnose, explain, inspect, or reproduce.
• A bot posts a cause hypothesis without agreeing to implement it.

Judge the requested action, not the presence of a bot.

A fix artifact already exists

If an open pull request or merged commit plausibly fixes this report, switch to `references/verify-existing-fix.md`.

An artifact may come from the thread, tracker issue, repository history, or pull request search. A claim without a commit or pull request is not a fix artifact.

If a person owns the work but has not produced an artifact, stop. Do not race them.

4. Open an optional operations thread

If `slack.operations_channel_id` is configured, the coordinator may create one root status message there. This is the only allowed root post in the repro workflow.

Store its coordinates as `OPERATIONS_CHANNEL_ID` and `OPERATIONS_THREAD_TS`. Never confuse them with the source coordinates.

Use the configured plain Unicode status strings. Keep status text short:

• Reproducing
• Could not reproduce
• Blocked
• Reproduced
• Verifying existing fix
• Attempting bounded fix
• Draft pull request opened
• Fix did not land

Prefer configured Cursor Slack actions. Use `BENNY_SLACK_BOT_TOKEN` only when the user configured it for a narrow missing capability such as editing this one status message. Never expose the token to a worker.

If no operations channel is configured, keep detailed status in the automation run output. Do not substitute a source-channel root message.

5. Load and check the control adapter

Read `references/control-adapter.md` and the completed map at `con