hypothetical-walkthrough

Hypothetical Walkthrough

Use the requested effort, defaulting to medium: Low gives a concise, focused end-to-end scenario; Medium uses representative end-to-end scenarios to reveal interactions and transitions; High simulates agent-generated user stories step by step across every relevant change and reaction. When no scenario or user story is supplied, state the contextual interpretation and ask whether to proceed; when no interpretation is supportable, ask which scenario or user story to simulate. When the target under test is absent or unclear, ask which system or process to trace. Begin the walkthrough only after both the scenario or user story and target under test are clear. Trace the configured system in ordered, step-by-step form from entry to completion, following how its parts, actors, and state interact. Let the goals and evidence direct attention rather than a fixed checklist. For each applicable step, keep a branch-local binding ledger: the literal instruction and source; consumed field, value, and type with its supplier; declared guard or none; assignments, overwrites, and output variants; and the next consumer or first incompatibility. Keep producer branches distinct until the source stops or rejoins them. Treat unanswered interactive prompts as typed unknowns until a declared answer or default; an entry contract can be the first blocked handoff, and later operations are separately counterfactual. Simulate actors following every applicable target instruction exactly. For every applicable step, inspect the material referenced skill, agent, script, API, or CLI contract. For every declared call, show its exact invocation (path or operation; each argument's name, type, symbolic value, and provenance) and the contract's applicable success, fallback, and error output variants. Build every downstream input from the producer's exact returned field and declared branch mapping; retain an opaque returned selector symbolically instead of assuming its identifier format. Apply explicit branch exceptions before generic templates, and trace declared adapters and caller handling before concluding a handoff fails or the workflow stops. Carry every unresolved prerequisite, branch guard, and blocker to its dependent downstream steps: a continuation after a blocked or unobserved step is counterfactual, names its enabling condition, and is never presented as unconditional. Treat the instructed path, name, operation, arguments, and mutation permission as part of the contract: follow only declared recovery, and report an unavailable instructed step as blocked while using alternatives only as diagnostic evidence or a proposed repair. Inspect source and caller-provided runtime evidence read-only; do not perform simulated calls or file mutations. Do not skip, invent, or silently repair a contract step: retain known error branches and mark unresolved prerequisites or ambiguous inputs conditional. Contrast the expected flow with repository and runtime evidence. Mark facts, inferences, and unknowns; do not invent missing scenario facts or branch conditions, and keep unknown-dependent steps conditional. This is a simulation, not an observed end-to-end demonstration. Report process, system, or transactional frictions, tensions, contradictions, and outcomes unexpected from the stated goals. Give each finding's evidence, impact, and a concrete validation check. End every report by offering to address, backlog, or discuss/split the findings.