Five open issues, three of them misdiagnosed by their reports, and staging as a service (2026.9.11.2)

[Sunrisepeak]

Two goal documents, one PR, one version. Commits are the checkpoints.

.agents/docs/2026-09-11-six-open-issues-analysis.md -- the analysis, the
self-review that changed one of its plans, and the criteria each fix has to
meet. .agents/docs/2026-09-11-distribution-plugins-and-platform-decomposition.md
section 11 -- the implemented distribution work read from nine angles.

Every report was right about its symptom; three were wrong about the cause

#606 -- the scanner read inside comments, in both directions. Block-comment
state never existed in the file's history: git log -S over
src/modgraph/scanner.cppm returns no commit that ever added one. So the
bisect to "after 2026.9.7.1" dates when the defect became audible, not when
it was introduced, and the malformed-name refusal added at 2026.9.9.1 (#594) is
correct.

The unreported form is worse. export module y; inside a block comment made a
plain .cpp the recorded producer of gcm.cache/y.gcm, a BMI the compiler
never writes -- and a file that legitimately imports y was then told
imports must be built before being imported, an ordering problem that does not
exist, while the real provider was never searched for.

And the other direction, also unreported: a commented-out raw-string opener
put the raw-string pass into a state it could not leave, blanking every
following line until a )" that never comes. Real imports were invisible to
the scanner and visible to the compiler -- a missing dependency edge, which
is a build-order race rather than a deterministic refusal.

The root cause is an argument written down as settled, in the source: "Ordinary
"..." strings are intentionally left as-is: the import/module matcher only
fires on lines whose trimmed text starts with the keyword, which a string body
can only do when it spans lines (i.e. a raw string)." The premise holds and the
enumeration is short by one -- a block comment can do it too.

One pass over three states now. tests/e2e/639 holds eight criteria, two of
them properties that were already correct and must not be lost (/* */ import x; must still record the import; "a /* b" must not open a comment). Against
released 2026.9.10.2, six of the eight go red.

#604 -- a two-token switch lost its switch. The host-module flag collector
de-duplicated per token and was written for the one family whose marker is a
single idempotent word:

family	useFlags	tokens
GCC	-fmodules	1, idempotent
Clang	-fmodule-file=<name>=<path>	1, unique
MSVC	/reference, <name>=<path>	2, first one repeats

/reference was already in the list from the bundled mcpp module, so an inner
host module's pair lost its first half and cl read <name>=<path> as a source
file name (C1083). Clang is immune by construction, which is why the defect was
specific to the one toolchain selection that reaches import std; at c++20 on
Windows.

Appended verbatim now, de-duplicating nothing. The comment being replaced stated
the filter's whole value -- "repeating it is harmless but noisy" -- so it bought
a tidier argv and paid with a broken command line. Plus
mcpp::toolchain::orphaned_reference as a reader that refuses before the
command runs, because C1083 names the module and the BMI and never names the
missing switch.

#603 -- the level is a property of the STL. The report's fix needs one
correction: std_module_min_level(tc) reads tc.version, which on the clang
path is clang's, against an MSVC threshold -- clang 20.x would pass it by
accident and clang 19.x fail it wrongly. The binding version is in the path of
the std.ixx already selected. One function, both paths, and a test that the
two forms agree for a well-formed installation.

#564 -- two dead keys wanting opposite answers. default_jobs gained a
reader: it is the only level that can hold a machine fact, and it also bounds
mcpp test (documented, because one key with two behaviours has to be).
default_backend was removed: BackendKind has two values and src/build/ has
one backend. The test asserts the precedence, not the wiring -- a fixture that
only sets the global value would pass with the parameter wired above
MCPP_JOBS.

#599 -- a check that had run in zero CI jobs. Three defects, not two: the
hub path was written for the current layout while naming a historical tree, the
uninit branch printed a note that cannot turn a job red, and there is no
bench workflow -- so the test's own justification for the note was false. All
three fixed; the note now fails under CI=true and stays a note locally.
Verified in both directions.

Staging is a service, not a precondition (the original subject)

mcpp pack --format <name> staged unconditionally before dispatching and let a
staging failure fail the command. For tar / dir that is right -- the staged
tree is the artifact. For a dispatched format it is one input the provider may
or may not want, and treating it as a precondition made every dispatched format
unreachable on any target whose built-in packaging is refused. Measured on
macos-15: --format app never reached the dispatch, because the built-in
closure walk uses LD_TRACE_LOADED_OBJECTS and dyld answers it by running the
program. The engine was answering a question the provider was not asked.

Verification

109 unit tests pass, tests/e2e/638 (nine cases) and tests/e2e/639 (eight)
pass, tests/e2e/233 passes with the submodules checked out and fails when they
are absent under CI. 266_pack_refuses_a_macho_program A/B'd byte-identical
against released 2026.9.10.2.