ACTUAL API EXECUTION · OCTOBER 25, 2026
A small
verified change
Ask a question. Change one file. Build it, test it, and return to the same conversation.
This walkthrough uses the results of a real Mojow run in a disposable project fixture. It is a recorded transcript with execution evidence; no actions run when you open this page.
Download the transcript01 / START A CONVERSATION
A question, and something to remember
The new disposable chat starts without an existing model thread. A first message establishes the conversation.
REQUEST
What is 7 times 8? Please remember the word fern for this conversation.
ACTUAL REPLY
7 times 8 is 56, and I’ll remember “fern” for this conversation.
02 / MAKE ONE CHANGE
Small scope.
Visible result.
The request names Greeting.cs, requires reading and hashing before writing, protects two other files, and asks for a Release build and test.
The runner completed read, hash and guarded write in order. Each step passed on its first attempt.
GREETING.CS · BEFORE
public static class Greeting
{
public const string Message = "Draft";
}
AFTER
public static class Greeting
{
public const string Message = "Ready for review";
}
Program.cs and Acceptance.csproj: byte-for-byte unchanged.
Read the full scoped request
In this disposable portfolio demo, change only Acceptance/Greeting.cs so Greeting.Message equals "Ready for review". Read and hash Greeting.cs before editing; use its actual current SHA-256 as expectedSha256 for the guarded write. Do not modify Acceptance.csproj or Program.cs. Build and test only Acceptance/Acceptance.csproj in Release. The test target runs a compiled behavior assertion. Report actual build/test exit codes and the assertion output in a short answer. Do not inspect or change other files or projects, install dependencies, restart services, or publish anything.
Inspect the file hashes
Before / supplied expectedSha256
1552e21578f75eefdb31959c0dd0027725e56ceff82d7a8548969a4db8bcd929After
1a45c80973bd022a816433d2e9b627f9f037ff97edbff5f24f54e9256a44196603 / CHECK THE BEHAVIOR
A passing build.
A real assertion.
Both commands targeted only the fixture project in Release. The test target runs compiled code that checks Greeting.Message and returns a failure code if it is wrong.
These outputs came from the same edit request. The fixture had been restored and compiled beforehand; its baseline assertion failed on “Draft.”
BUILD · EXIT 0
Acceptance -> Acceptance\bin\Release\net8.0\Acceptance.dll
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:01.27
TEST · EXIT 0
Acceptance -> Acceptance\bin\Release\net8.0\Acceptance.dll PASS: compiled Greeting.Message equals Ready for review.
04 / RETURN TO THE WORK
The conversation continues
The demo chat was left and reopened through the app API. Its conversation and model-thread identities stayed the same.
After this check, the original chat was restored and idle. Existing conversations and earlier demo evidence were preserved.
REQUEST AFTER REOPENING
What word did I ask you to remember earlier in this conversation? Reply with just that word.
ACTUAL REPLY
fern
WHAT THIS SHOWS
Evidence, with its boundaries
This is one successful run against a small prepared fixture. It does not establish that every project or workload will pass. No live Stop interruption was performed in this demo; Stop regression tests are separate engineering evidence.
Two earlier attempts are retained: one failed because its new fixture lacked restored project assets; another failed while preparing context, before any edit. That second failure exposed a task-cleanup gap still recorded for follow-up. Neither is counted as this successful run.
The transcript omits internal identities and replaces absolute fixture paths with Acceptance. The existing video tour remains labeled as sample data. This page is API evidence, not new desktop footage.