How a change reaches production.

Development runs across two machines that are kept unequal on purpose: a full environment on the development workstation, where the database lives, and a disposable cloud container where the code is written and tested without any database at all.

The workstation, phoenix-dev26.

• The solution is opened in Visual Studio from the project root and run under Kestrel through the project launch profile at https://localhost:51880, with a plain HTTP companion port, in the Development environment.
• The application reaches SQL Server directly. By the owner's ruling it reaches the production catalogs instead of a restored development copy, over a connection string held in a system environment variable.
• A user secrets identifier exists in the project file but is unused in practice; configuration comes from the environment.
• One known trap: Razor views compile into the same assembly as the page models, so when a change in a .cs file appears and a change in a .cshtml file does not, the incremental build is reusing a stale view. The cure is to delete the obj and bin folders and rebuild.
• Schema scripts are run by the owner, by hand, per catalog, from the owner's own SQL client.
• A single command, verify.cmd, builds the solution, runs four probes, starts an isolated instance on its own port, signs in, opens all sixteen report pages and downloads each as a PDF. Its sample mode performs the same run against fixtures with no database at all.

The cloud container has a .NET 8 SDK, a build tree and no database whatsoever.

• The absence of a connection string selects sample mode, in which fixture implementations of the finance, reports, calendar, VAT and document stores answer every query; the launcher refuses to start if a connection string is present.
• The fixtures are built from the company's own documents and figures, so a test can assert against numbers already held on paper.
• A headless browser drives the running application for probes, screenshots and PDF rendering.
• A local stand-in answers in place of the AI endpoint and the market and exchange-rate feeds with exact canned responses, so arithmetic can be proved with no model in the loop.

Gates. Thirty-seven gate scripts and four source sweeps are run against each round.

• Some are static scans that assert a property of the source, such as the absence of an unnamed projection inside a CTE, or of any long hexadecimal literal in a configuration file.
• The more valuable ones drive the running application. The most expensive lesson of this project is that a test which never runs what the user runs cannot see a runtime fault.
• Gates assert the rule a round settled, not the expression that shipped, and they strip comments before asserting, a correction that had to be made four separate times.

Crossing between the machines. Files move over the desktop file bridge under a fixed procedure:

• before the first edit of a round, every file the round might touch is hashed on the workstation's disk;
• before the commit, the same files are re-staged and compared by content;
• after the commit, both sides are hashed again and the combined digest compared.

Shipped is a claim about the workstation's disk, never about the build container.

Deployment copies exactly four things to the live site: the entire static web folder, the application assembly, its symbols and its executable. Configuration files are not copied, so live settings and secrets survive a release. The application pool is recycled after the copy, and the pre-publish checklist clears the health token and confirms the diagnostics class is gone.

Work is delivered in numbered rounds. The current build is v31.454, which shows how the project has been run: many small, complete, verified deliveries instead of long branches. A round begins with the owner's request, is turned into a matrix of rulings the owner accepts or changes, and then ships whole. A round is split only for work that cannot be done yet, such as an unanswered diagnostic or a decision only the owner can make.

Every round leaves a written record.

• A round note under the project's documentation says what changed and why.
• An assumption register records each judgement that could be wrong: numbered, tagged in the code beside the line it governs, risk-rated, and accompanied by the SQL that would settle it.
• Where a decision reverses an earlier one, the earlier ruling is struck through and annotated instead of deleted, so the history of a decision stays readable.

Four standing rules shape what may be done without asking:

• Secrets live only in system environment variables, never in a file the web server can serve and never pasted into a conversation.
• No new package may be added to the project, which is why the Web Push implementation, the PDF writer and the calendar invitation parser are all hand-written.
• No schema change, including a new index, is made without the owner's approval, and every script is written to be guarded and re-runnable and is run by the owner, per catalog.
• Posted accounting data is never altered to compensate for a presentation problem, and historical records are never bulk-corrected as a side effect of a fix.

Proof is layered.

• The build must be clean.
• The sweeps check the source for the known classes of mistake.
• The gates assert the rules.
• Probes drive the running application.
• The final check is always a hash comparison against the workstation's disk.

Where the sandbox cannot see something, the report says so. The clearest case is SQL: no query executes in the build container, so a query change is proved statically and by inspection until it runs on the live catalogs, and the round report states this.