feat(kernel-utils): declare the narrowing API surface - #1049
Draft
ci-belphegor wants to merge 1 commit into
Draft
Conversation
Fix the signatures of narrow and join and export them alongside a fully implemented pathUnder, so that callers and deltas can be written against the API before the algebra behind it exists. Both narrow and join throw; the changelog says so. pathUnder([]) matches every ..-free segment array rather than throwing. It is the top of the prefix lattice and a well-defined element of the vocabulary; a capability for which unbounded authority is a mistake rejects an empty prefix in its own config validation, where throwing here would buy nothing anyway since the caller could write the pattern by hand. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ci-belphegor
force-pushed
the
grypez/narrowing-3-api-surface
branch
from
September 11, 2026 11:42
f885dec to
2c386ec
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
Declares the narrowing API without implementing it:
NarrowingDelta, andnarrow({ name, base, delta })/join({ name, refs })with final signatures andthrow new Error('not implemented')bodies.pathUnder(segments)is fully implemented, since it is six lines with no dependencies and the next PR needs it to express real deltas.This exists so that the end-to-end test vat in PR 4 can bundle. A vat importing
narrowbefore it exists fails at bundle time and takes the whole test file down, whichit.failscannot absorb.Notes for reviewers
baseis typedobject, and that is not laziness. A real exo does not satisfyMethods:Methods = Record<RemotableMethodName, CallableFunction>demands an index signature, whileGuarded<M>is an intersection carryingRemotableObject's non-callable[PASS_STYLE]andSymbol.toStringTag, so it has none.Partial<Methods>(whatsheavesuses forSection) andRecord<string, unknown>fail identically — all three verified withtsc.objectis the honest floor, and it accepts a promised base for free, which is correct since the forward goes throughE().The consequence lands on the return side:
Guarded<Methods>collapses underE()'s mapped type, becausekeyofan index-signature-only type yields nothing. So a caller who wantsE()method access on a narrowing must supply the type parameter explicitly —narrow<{ readFile: (p: string[], enc: string) => Promise<string> }>({ ... }). This is documented innarrow's JSDoc.pathUnder([])matches every..-free segment array rather than throwing. It is the top of the prefix lattice, and stripping the identity out of the combinator would costjointhe representable top the design doc asks for. Rejecting an empty scope is the config layer's job, which PR 12 does.Stack
PR 3 of 12. Base: #1048.