Test what a small interface can do in each state

Design tests from the specification below. Return the complete 18-pair matrix and eight cards requested, with rule references and explicit unknowns. A proposed check is a description of what to try later, not an observation.

SAMPLE INPUT
ORIGINAL SYNTHETIC SPECIFICATION
This is an imaginary file-preview interface. No real app, file or test session is supplied. A state means the condition the screen is in. A transition means the next condition after one action.

S1. Initial state: Empty. Its visible message is "No file chosen".
S2. Preview shows the selected fictional filename and the message "Check this file".
S3. Saved shows that filename and the message "Saved in this example". This label alone makes no promise about disk storage, upload or persistence.
S4. Action labels for the matrix are Choose file, Remove, Confirm, New file, Cancel, Reset.
R1. Empty + Choose file -> Preview. Use fictional name paper-demo.txt; no real file selection occurs in this writing exercise.
R2. Preview + Remove -> Empty; clear the displayed filename.
R3. Preview + Confirm -> Saved; preserve the displayed filename.
R4. Saved + New file -> Preview. Use fictional replacement name second-demo.txt.
R5. Preview + Cancel -> Empty; clear the displayed filename.
R6. Confirm is disabled in Empty; activating it must not leave Empty or display a filename.
R7. For every state/action pair not covered by R1–R6, the behavior and control availability are unspecified. Unspecified does not mean disabled, ignored or an error. Reset and page reload have no supplied behavior. No network, real storage or persistence contract is supplied.

REQUEST
Make one matrix with all 3 states × 6 named actions, marking each pair either specified (with rule and expected next state) or a question. Make six proposed manual test cards for R1–R6 and two blocked cards for Reset and reload. Give starting condition, action, expected state and visible result where known. Every card must say NOT RUN. Do not build or open an app, fabricate a real file, decide missing behavior or claim the tests passed.

Return the full requested written result. Keep every proposed test marked not run. Do not invent application behavior, observations or successful execution. Do not connect to any service or run commands.

Create a complete state/action matrix from my written interface specification and proposed manual cards for every specified transition or blocked action. Explain state, action and next state in plain language. For each unknown pair, ask a concrete question instead of choosing behavior. Show starting condition, action, expected state, visible result and source rule for each proposed card. Keep every card NOT RUN; separate reset/reload questions if those rules are missing. Do not build or access an app.

MY INPUT
Named states and the initial state: [replace with complete non-sensitive details, or explicitly state unknown]
Complete action list and approved transitions: [replace with complete non-sensitive details, or explicitly state unknown]
Exact visible messages and filename/data rules: [replace with complete non-sensitive details, or explicitly state unknown]
Explicit disabled actions: [replace with complete non-sensitive details, or explicitly state unknown]
Missing behavior and reset/reload/persistence boundaries: [replace with complete non-sensitive details, or explicitly state unknown]
Requested test format; no execution is authorized: [replace with complete non-sensitive details, or explicitly state unknown]

Use only MY INPUT for facts and rules. Ask for essential missing details instead of inventing them. Do not import sample values. Return the complete written result and questions that remain. Do not open or connect to an application, run a test, send, publish, upload, or change another service.