Three things Ben saw on the running application. All three made it read as still being the tool it was forked from.
1. The upstream manual
The upstream 50-page manual was committed in the repository root as MmdPdf.pdf (719 KB) and sat next to the build on the test box. It was never in build/payload-files.txt, so it never shipped — but the application restores the previous session on launch, so once it had been opened it came back on every start, and what Ben saw first was a full-page green upstream logo on black.
Not shipping something is not the same as it not being on screen. Removed and added to .gitignore so a source drop cannot bring it back. With no document, the application opens on its own empty view.
I had seen this brochure in my own screenshots yesterday and only wrote a note about it. That is why it reached him.
2. Scan was in the window chrome
It sat beside minimise, maximise and close. That was my misreading of "add scan to the main nav" — window chrome is not where a tool lives.
It is a toolbar button now, next to Print in the file group, carrying a caption in every label mode like every other tool (Str_Lbl_Scan in the glyph→caption map, Str_TT_Scan for the tooltip). The BandButton style it used has no other user and is deleted with it.
3. The version
The footer read v1.7.5, which is the upstream project's number — MainWindow.xaml.cs fills that label from the assembly version. MMD PDF is 2026.8.1 now.
Deliberately not 1.0: the pilot machines already carry a build numbered 1.7.5, and an upgrade has to sort above what it replaces or Intune reads it as a downgrade. The Intune detection rule moves to 2026.8.1.0 with it.
Not yet done
This has not been built or run. A peer session is driving the test machine for Ben's editing test, and a build rewrites bin\Release underneath the application they are using. The build, the signature from mmd-fsn-01, the repackage and the Intune upload all happen once they are finished, and the keyboard-and-mouse check goes with them:
Scan appears next to Print, with a caption, and opens the dialog
Nothing in the title bar but the mark, the file name and the window buttons
The footer reads 2026.8.1
Opening with no document shows the empty view, not the upstream manual
Three things Ben saw on the running application. All three made it read as still being the tool it was forked from.
## 1. The upstream manual
The upstream 50-page manual was committed in the repository root as `MmdPdf.pdf` (719 KB) and sat next to the build on the test box. It was **never in `build/payload-files.txt`**, so it never shipped — but the application restores the previous session on launch, so once it had been opened it came back on every start, and what Ben saw first was a full-page green upstream logo on black.
Not shipping something is not the same as it not being on screen. Removed and added to `.gitignore` so a source drop cannot bring it back. With no document, the application opens on its own empty view.
I had seen this brochure in my own screenshots yesterday and only wrote a note about it. That is why it reached him.
## 2. Scan was in the window chrome
It sat beside minimise, maximise and close. That was my misreading of "add scan to the main nav" — window chrome is not where a tool lives.
It is a toolbar button now, next to Print in the file group, carrying a caption in every label mode like every other tool (`Str_Lbl_Scan` in the glyph→caption map, `Str_TT_Scan` for the tooltip). The `BandButton` style it used has no other user and is deleted with it.
## 3. The version
The footer read `v1.7.5`, which is the upstream project's number — `MainWindow.xaml.cs` fills that label from the assembly version. MMD PDF is **2026.8.1** now.
Deliberately not 1.0: the pilot machines already carry a build numbered 1.7.5, and an upgrade has to sort above what it replaces or Intune reads it as a downgrade. The Intune detection rule moves to `2026.8.1.0` with it.
## Not yet done
**This has not been built or run.** A peer session is driving the test machine for Ben's editing test, and a build rewrites `bin\Release` underneath the application they are using. The build, the signature from mmd-fsn-01, the repackage and the Intune upload all happen once they are finished, and the keyboard-and-mouse check goes with them:
- Scan appears next to Print, with a caption, and opens the dialog
- Nothing in the title bar but the mark, the file name and the window buttons
- The footer reads 2026.8.1
- Opening with no document shows the empty view, not the upstream manual
Three things Ben saw on the running application that all read as "this is still
the tool it was forked from".
1. The upstream 50-page manual was sitting in the repository root as MmdPdf.pdf,
so it was the document on screen whenever it was opened or restored from the
last session - a full-page green upstream logo on black. It was never shipped
in the payload, but it was there to be opened, which is the same thing to
whoever is looking at the screen. Removed, and added to .gitignore so it does
not come back with a source drop. With no document, the application opens on
its own empty view.
2. Scan was in the title bar beside minimise, maximise and close. That is window
chrome, not a tool. It is a toolbar button now, next to Print in the file
group, with a caption in every label mode like every other tool. The band
button style it used has no other user and is gone with it.
3. The footer read v1.7.5, which is the upstream project's version. MMD PDF is
2026.8.1. Not 1.0: the pilot machines already carry a build numbered 1.7.5,
and an upgrade has to sort above what it replaces or Intune would read it as
a downgrade. The Intune detection rule moves with it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign-off log gains the design-system rebuild, the scan work, signing from
mmd-fsn-01 and the Intune publish, then the three defects Ben found by looking
at the running application and what was done about each.
Backlog: PDF-07, PDF-08 and PDF-09 go green (built, run and looked at on the
test machine at 800x600), PDF-17 and PDF-18 go green (signed, published), and
PDF-14 goes amber with the reason stated plainly - the copier conversation and
the dialog are proven, the page transfer has never met real hardware.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Three things Ben saw on the running application. All three made it read as still being the tool it was forked from.
1. The upstream manual
The upstream 50-page manual was committed in the repository root as
MmdPdf.pdf(719 KB) and sat next to the build on the test box. It was never inbuild/payload-files.txt, so it never shipped — but the application restores the previous session on launch, so once it had been opened it came back on every start, and what Ben saw first was a full-page green upstream logo on black.Not shipping something is not the same as it not being on screen. Removed and added to
.gitignoreso a source drop cannot bring it back. With no document, the application opens on its own empty view.I had seen this brochure in my own screenshots yesterday and only wrote a note about it. That is why it reached him.
2. Scan was in the window chrome
It sat beside minimise, maximise and close. That was my misreading of "add scan to the main nav" — window chrome is not where a tool lives.
It is a toolbar button now, next to Print in the file group, carrying a caption in every label mode like every other tool (
Str_Lbl_Scanin the glyph→caption map,Str_TT_Scanfor the tooltip). TheBandButtonstyle it used has no other user and is deleted with it.3. The version
The footer read
v1.7.5, which is the upstream project's number —MainWindow.xaml.csfills that label from the assembly version. MMD PDF is 2026.8.1 now.Deliberately not 1.0: the pilot machines already carry a build numbered 1.7.5, and an upgrade has to sort above what it replaces or Intune reads it as a downgrade. The Intune detection rule moves to
2026.8.1.0with it.Not yet done
This has not been built or run. A peer session is driving the test machine for Ben's editing test, and a build rewrites
bin\Releaseunderneath the application they are using. The build, the signature from mmd-fsn-01, the repackage and the Intune upload all happen once they are finished, and the keyboard-and-mouse check goes with them: