# Repeated Workflow Discovery

Use this reference when Session Evidence must decide whether recent requests
contain repeated procedure demand. It is semantic comparison, not a keyword
detector or a request to open raw sessions.

## Analysis Model

- A **session** is a transport container, not one workflow or several runs.
- A **Workflow Run** is one root goal plus its ordered follow-ups, work trace,
  checks, recovery, delivery, and acceptance boundary.
- A **root candidate** is a repeated goal and stable first-prompt input shape.
- A **workflow candidate** also repeats ordered stages and a stop boundary.

Keep `goalConfidence` separate from `procedureConfidence`. First prompts may
support high goal confidence while procedure confidence remains unknown.

## Phase 1: First-Prompt Pass

Read only each `requestRoots` entry's `request.summary`, `ref`, `contextGroup`,
optional `candidateRef`, and provider label. Treat the summary as the root of a
possible Workflow Run, not as proof of later actions or results.

Cluster roots semantically using all of these dimensions:

1. the user's underlying goal;
2. the target or artifact type;
3. the stable input shape, such as an issue, screenshot, log correlation id,
   failing test, or review link; and
4. the requested acceptance boundary, when one is stated.

Shared words, repositories, paths, product names, or generic verbs such as
fix, analyze, review, test, and submit are insufficient. Keep a cluster only
when at least two distinct comparable Task Episodes support it.

Count independence conservatively:

- prefer roots from different `contextGroup` values;
- `occurrences`, repeated turns, retries, or copied history count as one run;
- several Episodes in one context group do not establish independent demand;
- identical forked roots without independent later traces must be deferred;
- keep provider evidence separate unless the lead explicitly joins it.

If `omitted.requestRootBudget` is non-zero, set `scanStatus: incomplete` and
state that discovery covers only the emitted root portfolio. Never claim that
the full 7- or 30-day population was clustered. Bound the result to the three
strongest clusters and retain at most three representative root refs per cluster.

## Phase 2: Candidate Expansion

Only after a root cluster passes Phase 1, follow each available `candidateRef` to
inspect matching trace, checks, repair, result, and mechanism facts. Never expand
unrelated candidates. Without two linked candidates, keep procedure confidence unknown.

Normalize observed actions into stages such as intake, prepare, inspect,
reproduce, diagnose, approve, modify, verify, recover, deliver, and review.
Preserve their order. A follow-up such as "still wrong" or "submit it" has
meaning only relative to its root and is never a standalone workflow.

Call a stage **core** only when at least two independent runs support it. Keep
a one-run stage **optional**. Promote `level: goal` to `level: workflow` only
when at least two runs repeat both an ordered core and a verification or
stopping boundary. Missing trace or result evidence stays unknown.

## False-Positive Firewall

- Repeated commit, publish, or review requests alone are a thin delivery tail,
  not proof of the workflow that preceded them.
- Repeated user corrections show friction, but not necessarily a stable
  procedure or the correct reusable intervention.
- Explicit use of an existing Skill is coverage evidence. It is not evidence
  that another Skill should be created.
- A recurring log-inspection step may be a backend diagnosis component without
  proving a complete hotfix workflow.
- Missing checks, outcomes, or assets are unknown; absence in the supplied
  facts is not evidence that the practice is absent.

## Return Contract

Report `scanStatus: complete|incomplete`. For each retained lead, report `candidateId`, `level: goal|workflow`, normalized goal, stable input shape,
provider-labelled root refs, core and optional stages,
`goalConfidence`, `procedureConfidence`, evidence limits, next evidence to
inspect, and `decision: candidate|defer|reject`. Explain the semantic match in
plain language. Do not expose raw prompts, local paths, or Session ids.

Do not recommend `Create Skill` or `Extend Skill`. The lead must first join the
candidate with Project and Agent Customize evidence, compare existing asset
coverage, and route uncovered repeatable work through Loop Discovery.

## Calibration Examples

- Independent roots asking to repair visible UI defects from screenshots or
  symptoms can form a `frontend-ui-bug-repair` goal candidate. Only repeated
  reproduce -> modify -> verify -> deliver promotes it to workflow.
- Bug roots that repeat correlated log inspection support a backend diagnosis
  component, not necessarily a whole hotfix flow.
- Roots that invoke `skill-creator` form a covered demand lead; they do not
  justify creating another Skill.