Workflow trial protocol

This is a prepared protocol, not completed user research. No participants have been contacted and no results have been recorded.

The maintainer selected general automation users as the primary audience. Recruit at least three people who automate tasks, including someone learning scripting. Explain that Zy is experimental. Use synthetic fixtures from the repository and let participants start from the automation quickstart without coaching their first attempt. The completed engineering walkthrough is separate from these trials.

Task	Observable result
Run the configuration validator on its valid fixture	Participant locates the command and explains the success report
Run its invalid fixture and correct a copy	Participant identifies a violated rule and makes a valid data change
Modify a shared module function	Participant uses definition navigation, finds the export, and makes a working change
Diagnose an introduced syntax error with `check`	Participant finds the file/line and fixes the error
Format the changed script	Participant understands stdout, write, and check modes

Record elapsed time, commands attempted, documentation used, errors encountered, assistance required, and the participant’s explanation of the result. Do not collect personal inventories or credentials. Report observations rather than inferring expertise from a failed task.

For each trial, copy this record into private research notes:

Participant alias / role:
Build version / OS / installation method:
Task outcomes and elapsed time:
Misunderstood output or documentation:
Assistance required:
Participant's explanation of the failed rule:
Would this replace an existing task? Which one?
Smallest change that would make this useful:

Acceptance requires three completed trials with understandable success/failure reports, plus a ranked list of observed friction and concrete fixes. Time is a comparison measure, not an invented pass threshold. Bring recurring issues back to the roadmap before adding live AI integrations.