A community theater receives caption files for two Saturday screenings. The afternoon show, Harbor, and the evening show, Echo, have separate screening IDs even though they share a date. The duty editor needs to verify that the correct language tracks appear in each preview and give the vendor reproducible evidence when something goes wrong. Use fictional screenings, clips, and dialogue to rehearse the workflow before connecting it to a delivery inbox. The handoff should contain the asset version, file inspection results, browser evidence, and the editor's acceptance status.
Trigger a check from a delivery record
Define which fields make a delivery actionable. Require a screening ID, asset version, expected languages, and an approved preview environment. The subject line can help classify incoming mail, but a request saying only “check Saturday's captions” should return the two candidate screenings and ask which one to use. Store a run under the screening and version together. If the vendor sends the same version again, show the existing run. If a newer version arrives, start a separate check and record which result it supersedes.
Begin with read-only file inspection. Check that each caption file decodes, that every cue ends after it starts, and that the final cue fits within the clip. Apply the theater's overlap rules to a fixture before using them on deliveries. Two speakers may intentionally share a time range, while a duplicated cue on the same track may be an error. Report the cue number, time range, and reason. If a parser rejects a file, retain the filename and failing line. A separate rehearsal fixture can still test the preview interface while the vendor corrects that file.
Use the linked Webapp Testing skill during browser verification. It needs a reachable preview site, an authorized test account where sign-in is required, and a playable clip with expected captions at named timecodes. Open the screening, switch tracks, pause at an expected line, and seek to the next scene. Capture the visible track label and the text rendered at that time. Include a clip with no captions to check the player's empty state. Have an editor compare the actual translation with the script. A browser run records what the audience can see, while the script review establishes whether the line is correct.
Run independent checks and merge by version
Give the file inspection and preview inspection separate inputs and outputs. The file step needs the delivery manifest and caption assets and returns cue defects and questions for the editor. The browser step needs a preview address and the expected asset version and returns available tracks, interaction results, and evidence. Run them in parallel when each can identify its version and neither writes to shared assets. Otherwise, make the dependent step wait for the version it needs.
Suppose the file checks pass for Harbor version 7 while the preview still reports version 6. Retain the successful file result and record the preview as stale. Once the preview updates, rerun only the browser branch. If both branches report version 7 but a track is missing, compare the manifest's language list with the preview configuration. Record who owns the next action, such as the vendor replacing a broken asset or the site maintainer correcting the track mapping.
When a useful check repeats across productions, turn its stable steps into a skill instruction. A track switching check can specify a playable clip, two known tracks, and a timecode with different expected text for each. Test the instruction with two screenings and a clip that has no captions. Keep a show's particular dialogue and timestamps in its fixture. After changing the instruction, replay one known failure and one known pass before adding the new version to the approved catalog.
Decide when a run can retry and when it should hand off
Track four stages: waiting for preview, checking the version, running browser cases, and assembling evidence. Give each stage a timestamp, input version, and outcome. If rendering is still in progress, poll the approved status view until a set deadline. If a connection drops, retry a limited number of times and record each attempt. If the correct version plays with visibly mistimed text, preserve the failing timecode and hand the issue to the editor. A permission error goes to the person who manages the account.
Before adding an external tool, document what files it receives, what identity it uses, and what result it returns. Evaluate the candidate with fictional dialogue and a test asset first. Keep formal acceptance in its own step, with a named editor and the exact version. If the vendor replaces a file after the editor accepted version 3, retain the version 3 record and queue version 4 for review. A retry of the browser check should never create a second acceptance record.
Rehearse the workflow before opening the inbox trigger
Run four trials. First, let both branches complete against the same version and check that the report identifies their inputs. Second, serve an older preview and confirm that only the stale branch reruns. Third, delay the preview beyond its deadline and confirm that the completed file inspection remains available. Fourth, configure the right language label with the wrong text and verify that the report includes a timecode, expected line, and actual line.
For example, at twelve minutes into Echo the track selector switches from English to simplified Chinese but the text remains English. Write down the screening ID, version, account role, player address, the two track labels, and the first affected cue. If the same asset works at another screening, record that comparison and its version. When the fix arrives, rerun the failing cue and one previously passing cue. If the clip was recut, ask the vendor for the replacement timecode before updating the fixture. Close the issue only after checking the new result against both cases.
Troubleshooting and common questions
The trigger ran but there is no report. Where should I look?
Find the last completed stage. If the event matched but inspection stopped, look for a rejected cue or an unreadable file. If inspection completed, check whether the preview is ready and the account can open it. The handoff should name the stage that stopped, the missing input, and who can supply it. Share file defects that are already confirmed so the vendor can start repairs while the preview is pending.
What if the vendor sends the same delivery twice?
Use the screening ID and asset version to find the existing run. If the files differ without a version change, hold the merge until the vendor confirms which set is current. Use the original run ID plus an attempt number when replaying the same inputs. This lets the next editor distinguish a retry from the first check of a new version.
Is a successful browser check enough for acceptance?
Check that the rendered track, dialogue, timing, and version match the editor's review. Also confirm that the rehearsed failure cases produced usable evidence. Attach acceptance to the reviewed version and preserve the earlier record if another delivery replaces it.