test(kernel-test): end-to-end narrowed fs, pending implementation - #1050
Draft
ci-belphegor wants to merge 1 commit into
Draft
test(kernel-test): end-to-end narrowed fs, pending implementation#1050ci-belphegor wants to merge 1 commit into
ci-belphegor wants to merge 1 commit into
Conversation
Eight end-to-end cases for attenuation by narrowing, every one marked it.fails so that it is green while it fails and turns red once it passes. Each names the pull request that removes its marker. Nothing in this repo used .fails before, so the file explains the convention. A green .fails proves nothing. It passes if the case fails for any reason at all — a typo, an unrelated throw, a vat that never launched — so what it buys is a forcing function and visible progress, not coverage. Each assertion gets its real scrutiny in the pull request that unmarks it. What each case fails on today, verified by unmarking the file and reading the errors: - the five local-exo cases: Error: narrow is not implemented - receives fs as an exo: rejected:target has no method "readFile", has [] - both config cases: Error: invalid cluster config, from SubclusterManager rejecting an fs config shape platformConfigStruct does not describe yet The vat calls narrow and join outside its probe helper, so a stub's own error rejects the whole method rather than being reported as a refusal. Without that, the two cases asserting a refusal would pass today on the stub's error instead of on a guard. Setup runs inside each case rather than a hook, so a rejected config fails the one case instead of erroring the file. The fs endowment's eventual type is claimed locally rather than imported, and the config that does not typecheck yet goes through a cast: it.fails absorbs a runtime failure, not a tsc failure. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ci-belphegor
force-pushed
the
grypez/narrowing-4-e2e-test
branch
from
September 11, 2026 11:42
c0a45c8 to
7dabc36
Compare
ci-belphegor
added this pull request to stack #1060
September 11, 2026 11:44
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.
Explanation
Adds an end-to-end integration test for narrowing, with every case marked
it.failsand a comment naming the PR that unmarks it. This is a ratchet: each later PR in the stack turns one or more cases green, so the middle of the stack produces visible progress instead of several PRs that demonstrate nothing.Nothing in this repo used
.failsbefore, so this introduces the convention.The first five cases use a base exo the vat builds itself with explicit
M.interfaceguards and need nofsat all. That is deliberate — it decouples the narrowing cases from thefsrework later in the stack.Notes for reviewers
A green
.failsproves nothing. It passes if the case fails for any reason, including a typo or an unrelated throw. The ratchet buys a forcing function, not coverage; each assertion gets its real scrutiny in the PR that unmarks it. Every case here was verified by unmarking it, reading the actual failure, and re-marking — five onnarrow is not implemented, one onE(fs).readFilereportingtarget has no method "readFile", has [], and two oninvalid cluster config.One thing here must not be refactored. The vat calls
narrow/joinoutside itsprobetry/catch, deliberately. Two cases assert a refusal by matching/^rejected:/u. If thenarrowcall sat inside the try, today's stub error would be caught and reported asrejected:narrow is not implemented, those cases would pass for the wrong reason, and the ratchet would be silently defeated. This is noted in the vat's JSDoc.The file must also typecheck at every point in the stack —
it.failsabsorbs a runtime failure but not atscfailure, which would break the package build for everyone. So thefscases are written against behavior, not types: the vat touchesfsas a loosely-typed global endowment.No changelog — test only.
Stack
PR 4 of 12. Base: #1049.