Workflow clarify

Turn a request into a behavior agreement the user confirms. Read the code first, then ask only what the code can't answer. No tickets, no code.

Read shared policies from ../workflow/ from this SKILL.md; if it's missing, stop and say so. Never use a workflow copy from another skills root. Its SKILL.md "Always" list applies here too (end every turn with the state line).

Before you start, check: rules are READY, or a recorded LIMITED_EXCEPTION covers this phase within its limits (workflow/RULES.md); the task is found and checkpointed (workflow/TASK-FOLDER.md), or the router left only its identity open: then ask "separate task or revision?" as Q1 of your first round, saying a separate task is best in a fresh chat; word the other questions so they hold for either answer, save the round as TASK-FOLDER.md's "identity pending" row says, and never ask it alongside approvals; the request is real work, not explain-only or a lightweight edit. If an agreement already covers this revision, go to workflow-specify. Application UI, meaning anything a user sees on screen (order, text, which rows or items show, layout, not only styling): first read ../ui-design/SKILL.md and ../rule-maker/rules/design.md, then trace. Options you offer never include new CSS, not even as a one-off exception.

1. Trace the journeys

A journey is one actor getting one outcome: trigger → steps → what they see. For each actor the request touches, trace in the code and record in FINDINGS (J-IDs, E-IDs):

1. Owner and callers: the code that owns the behavior, every other caller or entry point that reaches it, and the data and settings it reads. A caller no journey explains is a question.
2. Failures: what the actor sees on bad input, missing permission, offline or failed dependency, timeout, cancel, retry.
3. Compatibility: saved data, old callers, public interfaces, versions; whether the change extends or replaces what exists.
4. State and timing: remembered after closing or across devices; applies now or on the next action.
5. Limits: allowed dependencies or cost, target environments, privacy, stated exclusions.
6. Screen (UI only): each new element, the existing one it mirrors (file:line, tag, classes) and what python -X utf8 -I ../ui-design/scripts/class_rules.py <project-root> <classes> prints. A [needs context] rule, or a layout difference shown by --compare <from-parent> <into-parent>, means no match: ask design.md rule 4's question.