# MBN_STOCK_WEBVIEW workspace instructions

## Source and runtime assets

- Treat `C:\Users\MD\source\repos\MBN_STOCK_N` as read-only. Never edit, clean,
  reset, commit, or otherwise mutate that repository.
- The authoritative development runtime assets are under
  `MBN_STOCK_N\MBN_STOCK_N\bin\Debug\Cuts` and `...\Res`.
- Keep cut files, database credentials, vendor DLLs, licences, certificates, and
  machine-local configuration out of Git. Build-time links and ignored local
  deployment copies are allowed.

## Standing development Tornado2/PGM authorization

Recorded at the user's request on 2026-07-18. This workstation, its database,
Tornado2, and PGM are a development environment with no broadcast impact. For
MBN_STOCK_WEBVIEW migration, parity testing, and debugging on this development
environment, do not ask the user for a new round, plan hash, or per-command
approval before operating Tornado2/PGM.

The standing authorization includes launching and closing the development app,
CONNECT/DISCONNECT, PREPARE, TAKE IN, NEXT, Page NEXT, TAKE OUT, observing Network
Monitoring/PGM, and development-DB reads or writes needed by an in-scope migration
test. On designated playout PCs, normal Debug and Release application launches are Live.
Never use DryRun for app launches, tests, diagnostics, or migration validation.
Every in-scope playout run on a designated development playout PC must use Live
output. If required DB, K3D, target identity, allowlist, or authorization
validation fails, block startup with a clear error instead of falling back to
DryRun.

This is standing permission, not permission to guess after an ambiguous outcome:

- Confirm the target is the local designated development Tornado2/PGM endpoint
  before the first command of a run. A clearly different or production target is
  outside this authorization.
- Keep scene/path allowlists, vendor hash checks, STA serialization, and target
  identity checks enabled.
- On timeout, `OutcomeUnknown`, target identity change, or an unclear result, do
  not repeat, invert, or issue speculative cleanup commands. Stop dispatching,
  preserve evidence, diagnose read-only, and resume only from a known state.
- Do not force-terminate Tornado2/PGM or bypass K3D licence checks.
- Do not extend development database-write permission to a production database.

These safety boundaries are technical stop conditions. They do not require a
fresh conversational approval when the state is known and remains inside the
development scope above.
