Repository navigation
The kernel's dependency list is held to by a test (#1008) - #1181
Merged
Merged
Conversation
Packaging.md 7 proposed 'a check that fails on the commit that adds a dependency rather than on the release that ships it', and 11 states the kernel's third-party set as a list of four whose growth is a packaging decision. Neither was enforced by anything. KernelDependenciesTest is that check: the referenced assemblies against a written list, and the four non-System ones separately, because those are what a consumer's restore actually fetches. Writing it found the drift it exists to catch, which had already happened. The document said 13 referenced assemblies and the count was 14 -- System.Text.Json arrived with Core/Serialization. A framework assembly, so no consumer's restore changed and nothing noticed, which is the difference between no harm done and noticed. The list in 7 was a version behind for the same reason, and the reverse assertion turned up System.Runtime.InteropServices recorded and no longer referenced. Asserted in both directions, so a dependency that goes away is deleted rather than left asserting nothing. It sees one target framework, the one UnitTests builds; the netstandard2.0 leg is checked by nothing and that is recorded as its own gap rather than papered over here. Also corrects AGENTS.md's 'Decisions only a major version may take', which was wrong on two of its three entries. #721 was done additively in #1090 and is closed. #204 is no longer a value question: sqrt(x) and x ^ (1/2) are the same entity -- == answers True and Complexity is 3 for both -- since 1/2 started parsing as a Rational in 2.3.0, so only the printed form differs. Measured, both of them, rather than read off the list. Part of #1008. Full suite 9562 passed, 0 failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012sonx8iAspMiwRwokT1Ura
Rafael-SOWNet
added a commit
that referenced
this pull request
Sep 5, 2026
I merged #1181 green on net10.0 and it turned master's C# Test red on "netstandard" -- a reference assembly the netstandard2.0 leg resolves against and net10.0 does not. The gate asserted an exact set measured on one leg, so it was asserting a fact about the build rather than about the dependencies. Which framework assemblies a leg resolves is not a packaging decision. Which third-party ones it references is. So the third-party set is asserted exactly and in both directions, and the framework ones only as a set nothing may exceed: a leg resolving fewer is not an event, a leg pulling in something new -- System.Text.Json arriving with Core/Serialization is the case in point -- still fails. "netstandard" was also being counted as third-party by the second test, since it does not start with "System.", which is why both failed rather than one. There is now one predicate saying what a framework assembly is, and both tests use it. The test's own remarks record the mistake, because the shape of it is the useful part: a check that passes on the leg it was written against and fails on another is not a weaker check, it is a check of something else. Full suite green locally; the leg that caught this is CI's. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012sonx8iAspMiwRwokT1Ura
Rafael-SOWNet
added a commit
that referenced
this pull request
Sep 5, 2026
I merged #1181 green on net10.0 and it turned master's C# Test red on "netstandard" -- a reference assembly the netstandard2.0 leg resolves against and net10.0 does not. The gate asserted an exact set measured on one leg, so it was asserting a fact about the build rather than about the dependencies. Which framework assemblies a leg resolves is not a packaging decision. Which third-party ones it references is. So the third-party set is asserted exactly and in both directions, and the framework ones only as a set nothing may exceed: a leg resolving fewer is not an event, a leg pulling in something new -- System.Text.Json arriving with Core/Serialization is the case in point -- still fails. "netstandard" was also being counted as third-party by the second test, since it does not start with "System.", which is why both failed rather than one. There is now one predicate saying what a framework assembly is, and both tests use it. The test's own remarks record the mistake, because the shape of it is the useful part: a check that passes on the leg it was written against and fails on another is not a weaker check, it is a check of something else. Full suite green locally; the leg that caught this is CI's. Claude-Session: https://claude.ai/code/session_012sonx8iAspMiwRwokT1Ura Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
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
1 participant
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.
Packaging.md§7 proposed "a check that fails on the commit that adds a dependency rather than onthe release that ships it", and §11 states the kernel's third-party set as a list of four whose
growth is a packaging decision. Neither was enforced by anything.
KernelDependenciesTestis that check: the referenced assemblies against a written list, and thefour non-
Systemones asserted separately, because those are what a consumer's restore actuallyfetches.
It found the drift it exists to catch, already there
System.Text.Jsonarrivedwith
Core/Serialization. A framework assembly, so no consumer's restore changed and nothingnoticed, which is exactly the difference between no harm done and noticed.
System.Runtime.InteropServicesrecorded and no longerreferenced.
All three corrected here, and the document now points at the test rather than describing it in the
future tense.
Shape of the check
Asserted in both directions, so a dependency that goes away is deleted from the list rather than
left asserting nothing — the same pattern the rule-registry checks use.
It sees one target framework, the one
UnitTestsbuilds. Thenetstandard2.0leg carriesSystem.Memoryas a package rather than a framework reference and is checked by nothing. That is areal gap, and it is recorded as its own piece of work rather than papered over by loosening this one.
One thing worth knowing before grepping: the package
PeterO.Numbersships an assembly calledNumbers.Also corrects
AGENTS.md"Decisions only a major version may take" was wrong on two of its three entries, and that file is
read as authoritative:
DomainConditionIn(Domain)is a new method andCodomainwas left alone. The issue is now closed.
sqrt(x)andx ^ (1/2)are the same entity:==answersTrueandComplexityis 3 for both, since1/2started parsing as aRationalin2.3.0. Only the printed form differs, which is a
BREAKING-CHANGES.mdentry rather than a major.Both measured rather than read off the list, and the entry now says to re-measure before treating
anything on it as a constraint.
Part of #1008.
Checks
Full suite 9562 passed, 0 failed, 14 skipped.
🤖 Generated with Claude Code
https://claude.ai/code/session_012sonx8iAspMiwRwokT1Ura