Repository navigation
docs(#4445): the uncarried-asset finding is not scoped to the RID the bundle targets - #4580
Merged
Merged
Conversation
… bundle targets #4445 gates arming the container lane's refusal on a measurement: a full wave printing zero of either finding. I ran it. MeshWeaver.Plugins run 35051691749, job 104654803583 38 modules with a derived closure 0 unprobed-native, 6 RID-specific managed MeshWeaver.SocialMedia run 35178266255, job 105065263652 (pin 3.0.0-ci.8767) 1 module (7 closure lines — the reporting is live there) 0 and 0 The six are one package and one file: System.Security.Cryptography.ProtectedData at runtimes/win/lib/netstandard2.0/…, reached through MeshWeaver.Blazor, Azure.Blob, SelfUpdate.Aks, AI.AzureFoundry, AI.OpenAI and Mail.MicrosoftGraph. The only RID paths anywhere in that wave's log are those six runtimes/win/ reports and the runtimes/linux-x64/ assets the bundles DO carry — so the flagged file is a Windows implementation, in bundles that only ever load inside a Linux container, whose cross-platform façade under lib/netstandard2.0/ is already carried. So the criterion cannot be met as written, and the six are not six things to fix. Omitting a Windows implementation from a Linux-only bundle is correct. Arming today's rule would red six modules over an absence that is right — and the remedy #4445 prescribes for a victim (move to build: sdk, declare the carrier) cannot lift them: the SDK lane derives the finding from the same unscoped rule, so it refuses the same file, and there is no carrier to name because a flat closure has neither a slot for a foreign-RID copy nor a need for one. What arming needs first is therefore a correction to the finding itself: a RID-specific asset for a RID the bundle does not target is not an uncarried asset. That needs a target RID to compare against, which neither derivation is given today — a design change, deliberately not smuggled in with a bug fix. Verified: MeshWeaver.Documentation.Test builds Release -warnaserror with 0 Error(s); DocumentationLinkIntegrityTest green against an assembly proven to embed the new section (present control 1, absent control 0). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
Contributor
Contributor
Contributor
Contributor
Contributor
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
Correct the documented statements about target-RID inputs, SDK carriers, and native findings.
Get a fresh assessment by requesting another Copilot review.
Pull request overview
This documentation-only PR records the #4445 measurement and explains the RID-scoping gap affecting refusal arming.
Changes:
- Records scheduled wave results and affected modules.
- Explains why Linux bundles should not carry foreign-RID assets.
- Identifies RID-aware logic as the required follow-up.
File summaries
| File | Summary |
|---|---|
src/MeshWeaver.Documentation/Data/Architecture/ModuleClosureAccounting.md |
Adds measurement findings and RID-scoping rationale. |
Review details
Suppressed comments (2)
src/MeshWeaver.Documentation/Data/Architecture/ModuleClosureAccounting.md:173
- This overstates the limitation of the SDK remedy.
DepsClosure.UncarriedAsset.Describe()explicitly lifts a RID-specific finding with--with <file>(orMeshWeaverPackWith), so declaring a carrier can make the SDK pack succeed; it would merely be the wrong fix for a foreign-RID asset in a Linux-targeted bundle. Please distinguish “unnecessary/wrong to carry” from “cannot be carried.”
And the remedy #4445 prescribes for a victim — *move the module to `"build": "sdk"` and declare the
carrier* — cannot lift these: the SDK lane derives the finding from the same unscoped rule, so it
refuses the same file, and there is no carrier to name because a flat closure has neither a slot for
a foreign-RID copy nor any need for one.
src/MeshWeaver.Documentation/Data/Architecture/ModuleClosureAccounting.md:145
- These two findings do not have the same RID-scoping defect.
NativeContributions.UncarriedBytreats anativedeps section as already resolved to the image's RID and reports paths that the loader cannot probe; that layout remains invalid even when the RID matches. The measured cross-RID false positive is the portableruntimeTargetsmanaged asset, so this sentence overstates the native finding's scope.
**Neither finding is scoped to the RID the bundle actually targets**, and that is the whole reason
the container lane's refusal is still unarmed (#4445).
- Files reviewed: 1/1 changed files
- Comments generated: 1
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Comment on lines
+175
to
+177
| **So the criterion has to be corrected before it can be met:** a RID-specific asset for a RID the | ||
| bundle does not target is not an uncarried asset, and both lanes should say so — which needs a | ||
| target RID to compare against, a value neither derivation is given today. That is a design change, |
Contributor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Runs the measurement #4445 gates its arming on, and records what it found. No behaviour changes —
one doc section.
The measurement
#4445 says the container lane's refusal may be armed only after "a full container-lane wave … prints
zero occurrences of either literal", with the run ids and the denominator. Scheduled full waves,
read 2026-09-17:
35051691749/10465480358335178266255/105065263652(pin3.0.0-ci.8767)The Plugins denominator of 38 matches the issue's own "38 of Plugins' 41 bundles". The
SocialMedia figure is quoted from the module job, not the workspace job — the latter carries no
closure lines at all, so its 0/0 has a denominator of 0 and is not evidence.
Criterion 1 is not met. The positive control is the finding itself: the RID-specific literal
printed 6 times through the same reporter and the same shared wording, so the zero for the native
literal is the instrument working rather than the instrument silent.
What the six are
One package, one file —
System.Security.Cryptography.ProtectedDataatruntimes/win/lib/netstandard2.0/System.Security.Cryptography.ProtectedData.dll— reached throughMeshWeaver.Blazor,MeshWeaver.Azure.Blob,MeshWeaver.SelfUpdate.Aks,MeshWeaver.AI.AzureFoundry,MeshWeaver.AI.OpenAIandMeshWeaver.Mail.MicrosoftGraph.The only RID paths anywhere in that wave's log are those six
runtimes/win/reports and theruntimes/linux-x64/assets the bundles do carry. So the flagged file is the Windowsimplementation of a package whose cross-platform façade under
lib/netstandard2.0/is carriedalready, in bundles that only ever load inside a Linux container.
Why this blocks arming rather than being six things to fix
Omitting a Windows implementation from a Linux-only bundle is correct. Arming today's rule would
red six modules over an absence that is right.
And #4445's prescribed remedy for a victim — move the module to
"build": "sdk"and declare thecarrier — cannot lift these. The SDK lane derives the finding from the same unscoped rule
(
DepsClosurehas no target-RID comparison; I looked), so it refuses the same file, and there is nocarrier to name: a flat closure has neither a slot for a foreign-RID copy nor any need for one.
So the criterion has to be corrected before it can be met. A RID-specific asset for a RID the
bundle does not target is not an uncarried asset, and both lanes should say so — which needs a target
RID to compare against, a value neither derivation is given today. That is a design change, and this
PR deliberately does not smuggle it in: it records the measurement and names the decision.
Verification
MeshWeaver.Documentation.Testbuilds-c Release -warnaserrorwith 0 Error(s);DocumentationLinkIntegrityTestgreen — against a rebuiltMeshWeaver.Documentation.dllproven toembed the new section (present control 1, absent control 0), since a stale embedded asset is a known
false pass here.
Pairs-with: none — a documentation page; no public type or member is removed.
🤖 Generated with Claude Code