recording-ui-evidencelisted

# Recording UI evidence A demo GIF is an evidence claim: *this is what the software does at this commit.* That makes the recording conditions part of the claim, and it makes splicing, fixtures, and stale builds forms of misreporting rather than shortcuts. This skill owns the evidence chain from a running application to a published artifact. It does not decide whether a given change owes visual evidence at all — that is a project policy, and this skill is guidance rather than a mandate. **One storyboard equals one isolated run.** Every published frame comes from the same server, the same state roots, and the same scenario execution. If capture automation fails partway, discard its frames and rerun from fresh roots — never assemble a demo from two runs. ## Keep recording separate from publication - Recording produces frame images and one local `.gif`. It never mutates remote state. - Publication is a separate, final step, performed only when the task actually includes attaching the artifact. It never touches the change's own branch. - **Preserve the requested conditions.** A real-server or real-backend demo must not use fixture queries, mock transports, synthetic event injection, or test-only hooks. If credentials or the service are unavailable, **report that limitation** rather than substituting a fixture and calling it a demo. - **Never read or expose credential values.** Use the application's normal configuration path and a benign demonstration input. ## Stage the appl