Record application paths for product onboarding

Why use this

1. A product walkthrough can teach the wrong lesson if it records only a happy path or uses an account with permissions different from the intended user. A video may also reveal private data or hide failed steps behind an apparently smooth sequence.

2. A recording plan could define the starting state, role, expected checkpoints and privacy boundaries for each path. Product reviewers could decide which journeys need an authorized demonstration while keeping a storyboard separate from proof that the application works.

Why an agent / simpler alternative

Useful judgment

Translate a product question into observable states and identify missing prerequisites or role-specific branches.

Simpler alternative

Ask a knowledgeable teammate for a short demonstration when the requested path is familiar and infrequent.

Unsuitable when

Safe test data or an authorized test account is unavailable, or the path performs consequential production actions.

Proposed inputs

1. Name

   Walkthrough request

   Owner

   Product owner

   Minimum scope

   Named user role, task goal and desired path boundaries

   Quality check

   Specify which branches and errors matter to the learning goal.

2. Name

   Test-state description

   Owner

   Application owner

   Minimum scope

   Fictional account permissions and starting-state assumptions

   Quality check

   Exclude real customer information and destructive actions.

Access and setup — proposed or unknown

Proposed minimum

1. Offline screen descriptions and a recording storyboard without application access.

Compatibility unknowns

1. Unknown: current runtime, browser recording, test environments and data masking.

External actions requiring approval

1. Application access, safe test interactions, video retention or sharing and any production mutation.

Expected deliverable and review checks

Proposed artifact

Path-by-path recording plan with start conditions, checkpoints, privacy checks and unresolved branches.

Critical checks

1. Each planned recording identifies the exact role and initial state.

2. Skipped or failed steps would remain visible rather than being edited into apparent completion.

Missing output evidence

No new workflow run or output inspection was performed for this overlay; use the canonical source-outcome references.

Failure signals and proposed responses

1. Signal

   The planned account has broader permissions than the intended user.

   Why it matters

   The walkthrough may describe an inaccessible journey.

   Proposed response

   Adjust the role or clearly separate the privileged path from the requested scenario.

2. Signal

   A screen would expose personal customer details.

   Why it matters

   The recording creates an unnecessary disclosure risk.

   Proposed response

   Require synthetic test data or a verified masking plan before recording.

Effort and cost — unknown

Setup work

1. Define paths and safe starting states.

Ongoing review

1. Inspect later recordings for scope coverage and privacy.

Unknowns

1. Unknown: recording support, environment setup and walkthrough completeness.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

A fictional storyboard uses an administrator account for an ordinary-user task and includes a customer-detail screen.

Acceptance checks

1. Flag the role mismatch.

2. Require a synthetic-data plan without opening or recording an application.

Stop conditions

1. Live browser use, application actions or video capture is needed.

Limits

1. A storyboard check establishes no path coverage, application correctness or completed recording.