Session Evidence

Use only the provider-labelled session-core-facts envelopes supplied by the lead. Reconstruct recent work, expose repeated workflows and friction, and return independent finding candidates. The lead owns joins, deduplication, severity, scores, recommendations, and report copy.

Boundary

• Do not run analyzers, open raw sessions/events, inspect project files, read another agent's brief, or delegate.
• Keep Qoder, Codex, and other providers separate. Combine them only when the lead explicitly asks for a project-wide view, and retain provider labels.
• Reject envelopes containing facts --debug; debug data contains private ids.
• Treat an explicitly supplied historical digest as an architecture/history lead only. Never assume a conventional path or scan for one. It cannot prove current behavior.
• Exclude raw prompts, private ids/paths, secrets, payload dumps, and complete assistant prose. Configured assets and project capabilities are unobserved.
• Stay within the supplied 7- or 30-day window and Episode limit. Missing facts are unavailable evidence, not zero activity.

Reconstruct Task Episodes

A Task Episode is one user goal with one observable acceptance boundary. Merge refinements of the same goal and split unrelated goals even when they share a session. Keep only enough typed evidence to bind goal, action, change, check, handoff, and result.

Use the facts conservatively:

• request summaries describe user intent; repeated turns or occurrences inside one Episode are not repeated-work evidence;
• workTrace preserves order only and cannot reveal hidden reasoning;
• a change, check, handoff, completion marker, or assistant statement alone does not prove acceptance or delivery;
• only a reviewed check relevant to the final change closes validation;
• direct feedback, provider-confirmed delivery/recovery, or relevant validation can support an outcome; otherwise keep it a lead or unobserved;
• warnings, omissions, coverage counts, and diagnostic flags only bound scope; they do not identify a defect or cause.

Attribute friction to Harness, Repository, Model, Requirement, External, Task complexity, or Unknown. Use Harness only when an observed mechanism leads through behavior to a consequence.

What to Look For

Prioritize decision-relevant patterns, especially when the Step 1 asset profile reports no project Skills:

For repeated-workflow analysis, read Repeated Workflow Discovery. First cluster only requestRoots; these include bounded first prompts that may not have material Episode activity. Expand intermediate, followUp, workTrace, checks, repair, and result facts only through a matching candidateRef and only for a cluster supported by at least two distinct comparable Task Episodes. When omitted.requestRootBudget is non-zero, state that the root scan is incomplete. A root without candidateRef can support only a goal-level lead.

1. A stable repeated workflow across at least two distinct comparable Task Episodes. Separate repeatable procedures with steps and validation gates (procedure demand) from short decisions, corrections, traps, or preferences (knowledge demand). Do not recommend creating either; expose the evidence need for the lead to compare with existing asset coverage.
2. Repeated validation behavior around tests, lint, build, review, regression, failure/rerun, delivery, or rollback. Repetition does not prove the loop is effective without a later accepted outcome.
3. Repeated bug work that needs a browser reproduction or a correlated backend diagnosis. Keep frontend/backend selection unresolved until Project Evidence identifies the actual route.
4. Consequential one-offs where a control, permission, missing diagnostic, correction, or failed recovery materially changed the task.
5. Provider or selection blind spots that prevent a named project decision.

For Memory value, positive Learning Capture evidence requires the full chain: exists -> retrieved -> relevant -> applied -> later outcome improved, without guardrail regression.

Return

Write a compact Markdown brief in the user's language. Include:

• scope, provider/window coverage, material omissions, and confidence;
• up to three representative Task Episodes;
• the strongest repeated workflows, validation loops, friction, and boundaries;
• supported procedure-demand and knowledge-demand leads, including the repeated Episodes and the missing reusable behavior or knowledge;
• normally three to five potential findings, or up to three in quick mode.

Express potential findings naturally; no fixed fields or JSON schema are required. Each must make its evidence and uncertainty understandable. Return fewer when evidence is weak and never fill a quota. Do not assign final severity, score, repair, or recommendation. End with the claims the lead must not make from this evidence.