Set 7 Demo Take Console Bundle

The console bundle replays one copied runtime

This component reads the Demo Take Console's public Swift source and checks that its safety gates actually hold, without ever launching the macOS capture app. The Demo Take Console is a macOS app that records screen and microphone takes, drives FFmpeg through a Python helper, and hands the audio to an on-device WhisperKit transcriber. This component reads the app's public Swift source and checks that the safety gates in that source actually hold, without ever launching the app.

Three checks bind inputs, output, and ceiling

It copies eight Swift files, runs six source-token checks plus six paired deletion cases, and emits records of exit codes, counts, and booleans, never source bodies or logs. It copies eight Swift files into a public bundle, runs six checks that read those copies, then runs six paired negative cases that delete one guard and demand the matching check notice. It emits result records that carry exit codes, counts, and booleans, never the source bodies, recordings, or build logs.

The demo result stays metadata-only and local

A green run says only that the source contracts are present, not that capture, FFmpeg, or a model ever ran. A green run says the source contracts are present. It does not start capture, run FFmpeg, or dispatch a model.

Purpose

Do the source gates exist as source

A capture app is trusted with screen, microphone, and disk, so the narrow question is whether the gates written into its Swift source exist as source. A capture app is trusted with a screen, a microphone, and disk. The question this component answers is narrow: before anyone trusts the app to record, do the gates written into its Swift source exist as source?

Each check asserts a behaviour-carrying token

Because a file can name clamp yet ship an unclamped meter, each check asserts a specific behaviour-carrying token in the copied source rather than shape alone. Checking shape alone is not enough. A file can contain the word "clamp" and still ship an unclamped meter. So each check asserts a specific token that carries the behaviour: the start gate requires a chosen recording source and free disk, the global hotkey requires Control-Option-Command, the audio meter returns min(max(rms * 8, 0), 1), the transcriber guards a missing audio file. The checks read the copied source, not the app's live state.

How it works

Two entrypoints and two callbacks

run and run_batch7_demo_take_bundle both drive run_crown_jewel_organ with _evaluate for positive checks and evaluate_negative_case for mutation tests, over the fixture or the exported copy. run and run_batch7_demo_take_bundle both call run_crown_jewel_organ with two callbacks: _evaluate for the positive checks and evaluate_negative_case for the mutation tests. run reads the fixture input; the bundle variant reads the exported public copy. main wires the run and validate-bundle subcommands to the same runner and prints a result or a card.

Six engines over eight copied modules

_evaluate runs six engines, failing on any non-pass status or fewer than eight copied modules, with each engine reading its Swift file through _read and returning booleans plus a claim_ceiling. _evaluate runs six engines in order and collects a finding for any that does not return status: "pass". It also fails if the copied source manifest holds fewer than eight modules, the count in SOURCE_REQUIRED_ANCHORS. Each engine reads its Swift file through _read, which resolves the copied path under the exported bundle, and returns a small dict of booleans plus a claim_ceiling string.

The build witness runs swift build

The one engine that runs code, _run_public_witness, executes swift build and returns only the exit code, byte counts, and a Build complete! flag, claiming compilation and nothing more. The build witness is the one engine that runs code. _cached_swiftpm_build_witness calls _run_public_witness, which runs swift build and returns only the exit code, the stdout and stderr byte counts, and whether the string Build complete! appeared. The build log body stays out of the record. The claim is that the copied sources compile as a SwiftPM target, nothing more.

flowchart TD bundle["Copied public Swift bundle eight source files"] engines["Six engines build witness plus five source-token contracts"] negatives["Six negative cases delete one guard re-run that engine"] record["Result record exit codes, counts, booleans no source bodies or logs"] bundle --> engines bundle --> negatives engines --> record negatives --> record

Negative cases

Five mutations flip an engine to blocked

Five negative cases share _mutated_source_negative, which copies the bundle, replaces one token, re-runs the matching engine, and expects it to flip to blocked with its guard flag false. _semantic_runtime_exercises builds six negative results. Five share _mutated_source_negative: it copies the bundle to a temporary directory with _copy_public_bundle, replaces one token with _replace_copied_source_token, re-runs the matching engine, and expects the engine to flip to blocked with its guard flag now false. _observed_negative_case reads that flag per case.

The five named source mutations

The five mutations rewrite the helper path, remove the source blocker, drop a hotkey modifier, unclamp the meter, and delete the audio guard, and any check that still passes fails the case. The five source mutations are missing_helper_bridge (rewrites the demo_take_capture.py helper path), start_without_screen (removes the "Select at least one recording source" blocker), hotkey_wrong_modifier (drops .option from the modifiers), audio_meter_unclamped (replaces the clamp with a bare rms * 8), and transcribe_missing_audio (removes the audioNotFound guard). If a check still passes after its guard is gone, it was never testing the guard, and that case fails.

The sixth case checks the build witness

The sixth case, missing_swift_build_witness, runs swift build against an empty directory and expects a non-pass, since a success against nothing would mean the witness was asserted, not run. The sixth, missing_swift_build_witness, runs swift build against an empty temporary directory through _run_public_witness and expects a non-pass. A build that "succeeds" against nothing would mean the witness is asserted rather than run.

Prior Art Grounding

ScreenCaptureKit, FFmpeg, and WhisperKit lineage

The app follows the desktop capture-console lineage anchored by Apple's ScreenCaptureKit, FFmpeg, and WhisperKit, while this component borrows only the contract shape and stays at source-copy and fixture checks. The app follows the common desktop capture-console lineage: OS capture APIs, a command-line media encoder, typed recording state, a global hotkey, a level meter, and a transcription handoff. The public anchors are Apple's ScreenCaptureKit for screen and audio streaming, FFmpeg for encoding, and WhisperKit for on-device speech recognition on Apple Silicon. This component borrows the contract shape and keeps the exercise at source-copy and fixture checks.

Validation Result record Path

Run from microcosm-substrate/:

Output files and what a pass means

The run writes result, board, and validation-result record JSON plus an sign-off file, and a pass means every engine returned pass, the six negative cases blocked, and no source body reached a record. The run writes batch7_demo_take_console_capsule_result.json, batch7_demo_take_console_capsule_board.json, and batch7_demo_take_console_capsule_validation_receipt.json under the output directory, plus the sign-off file. The validate-bundle action re-runs the same checks over exported_batch7_demo_take_console_capsule_bundle. A pass means every engine returned pass, the six negative cases blocked, and no source body reached a record.