# Your first feedback loop: example scenario

One way to combine the earlier pieces on ticket-service into a loop from labeled issue to reviewed pull request, with repeated failures feeding back into the setup.

Source: https://ai-sw-factory.mellicci.dev/fundamentals/your-first-feedback-loop/example-scenario

## Scenario

In `ticket-service`, maintainers label small issues `agent-ready`, but every agent-written change still needs hand-holding. Someone starts the run, someone fixes the same convention in review, and the fix never reaches the next run. Here you assemble the pieces from the earlier pages into one small loop. This is one way to do it.

## Before → after

| | Before | After |
|---|---|---|
| Start | A person opens a session per issue | The `agent-ready` label starts a run |
| Quality | Depends on the run and the reviewer's attention | Hooks, tests and a reviewer subagent gate every run |
| Risk | Broad local permissions | Sandboxed, least-privilege CI job; a human merges |
| Consistency | The same review comment, every week | A repeated failure becomes a change to the setup |

## Design

**Diagram:** Three frames, one loop: a run is triggered, gated, and its failures change the setup.

- Trigger & run:
  - Labeled issue — #42, agent-ready
  - → CI starts
  - Sandboxed run — devcontainer, CI baseline
  - → reads
  - Context — instructions, skill, MCP
- →
- Gates:
  - Hooks — block, format, log
  - →
  - Goal loop — until tests pass, max 10
  - →
  - Reviewer — verdict per criterion
- →
- Outcome & learning:
  - Pull request — a person merges
  - → repeats?
  - Setup change — shipped in the team kit

```text
# Generic layout, names are illustrative
.github/workflows/agent-ready.yml  label trigger, headless run
.devcontainer/                run image
<instruction file>            project rules, points to src/db/
skills/add-migration/         schema-change steps
hooks/guard.sh format.sh log.sh
agents/reviewer               read-only review criteria
ticket-service-kit            plugin that ships all of the above
```

| Loop | What cycles | Ends when |
|---|---|---|
| Inner | Agent turns: act, run tool, read result | The agent stops |
| Quality | Tests, hooks, reviewer verdict | Tests pass and the reviewer approves |
| Outer | Issue → PR → learnings into the setup | A person merges and fixes the setup |

## Which piece does what

| Step | Concept | Role here |
|---|---|---|
| 1 | [Headless execution](https://ai-sw-factory.mellicci.dev/fundamentals/headless-execution/example-scenario) | The label starts an unattended run |
| 2 | [Sandboxing](https://ai-sw-factory.mellicci.dev/fundamentals/sandboxing/example-scenario), [security model](https://ai-sw-factory.mellicci.dev/fundamentals/security-model/example-scenario) | Built-in sandbox on, CI baseline applied |
| 3 | [MCP](https://ai-sw-factory.mellicci.dev/fundamentals/mcp/example-scenario), [instruction files](https://ai-sw-factory.mellicci.dev/fundamentals/instruction-files/example-scenario), [skills](https://ai-sw-factory.mellicci.dev/fundamentals/skills/example-scenario) | Read the issue, follow the rules, use `add-migration` |
| 4 | [Hooks](https://ai-sw-factory.mellicci.dev/fundamentals/hooks/example-scenario) | `guard.sh` blocks, `format.sh` formats, `log.sh` logs |
| 5 | [Loops](https://ai-sw-factory.mellicci.dev/fundamentals/loops/example-scenario) | Continue until `pnpm test` passes, 10 rounds at most |
| 6 | [Subagents](https://ai-sw-factory.mellicci.dev/fundamentals/subagents/example-scenario) | `reviewer` returns a verdict |
| 7 | Human review | A person reviews and merges the PR |
| 8 | [Plugins](https://ai-sw-factory.mellicci.dev/fundamentals/plugins/example-scenario) | `ticket-service-kit` ships the improved setup |

## What happens at runtime

One run for issue #42, "Add `priority` to tickets".

| Step | What happens |
|---|---|
| 1 | A maintainer adds `agent-ready`; CI starts the agent headless in the devcontainer image, sandbox on. |
| 2 | The agent reads #42 through the GitHub MCP server and the instruction file, which points to `src/db/`. |
| 3 | The schema changes, so the agent follows the `add-migration` skill. `guard.sh` blocks an attempt to edit an old migration; `format.sh` and `log.sh` run on each edit. |
| 4 | The goal loop runs `pnpm test`. Round 1 fails, round 2 passes. |
| 5 | `reviewer` returns a verdict: one criterion fails, routes use a different error shape than the convention. The finding goes back to the agent. |
| 6 | The agent fixes it, tests pass again, the reviewer approves, and the job opens a PR. |
| 7 | A person reviews and merges. The reviewer flagged the same convention on #37, so they add one line to the instruction file and ship it in `ticket-service-kit`. |

## What can go wrong

| Failure | How you notice | What to do |
|---|---|---|
| The loop amplifies a bad instruction | Every PR repeats the same odd pattern | Review setup changes like code; fix the line once, in the kit |
| Nobody owns the learnings | The same reviewer finding appears for weeks | Name an owner and look at repeated findings on a schedule |
| Gates are so strict every run fails | Runs hit the 10-round limit, PRs are rare | Loosen or split the gate; track the pass rate per gate |
| Cost creeps with each added gate | Run time and spend per PR rise | Measure cost per merged PR before adding a gate |
| Humans rubber-stamp PRs | Merges within seconds, bugs escape | Keep PRs small, show gate results in the description, sample reviews |

This is a starting point, not a prescribed design: swap, drop or reorder any piece to fit your own factory.