Files
MBN_STOCK_WEBVIEW/AGENTS.md

2.2 KiB

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. Prefer the existing Debug development-live profile and its ignored local authorization file; do not weaken Release/default DryRun behavior.

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.