Complete the hoist inside kernel: Completion imports, platform-bridge retags, affinity dispatch (D1/D2)

[coenttb]

Problem

Full-tier run 30615499446 at cf4875c fails on every platform leg with four kernel-owned defect classes (adjudicated dispositions from the 2026-07-31 migration-completeness audit: D1 — the unified vocabulary attaches on Windows too, no os-gating; D2 — the affinity kind-switch lives kernel-side only; platform apply surfaces are deleted by their owners):

1. Completion → Event visibility. Sources/Kernel Completion/Kernel.Completion.Submission.Opcode.swift:101:43: 'Event' is not a member type (+ Equatable/Hashable synthesis failures at 34:17). Kernel.Event.Interest moved into the Kernel Event target at the hoist; Kernel Completion declares no dependency on it.
2. Kqueue ID retag. Sources/Kernel Event/Kernel.Event.Source+Kqueue.swift:66/76: cannot convert 'Kernel.Event.ID' (Tagged<POSIX.Kernel.Event, UInt>) to 'Darwin.Kernel.Event.ID' (Tagged<Darwin.Kernel.Event, UInt>) — the re-anchored Darwin.Kernel.Event.Queue is a distinct nominal ID space.
3. Bare mechanism references. Kernel.File.Clone+CrossPlatform.swift:75/134 'Clonefile', :145/211 'Copyfile' not in scope on macOS branches; the Linux branches' bare Ficlone/CopyRange are the same class. Post-re-anchoring homes: Darwin.Kernel.File.Clone.{Clonefile,Copyfile} (swift-darwin-standard, Darwin Kernel Standard/Darwin.Kernel.File.Clone.swift:195/198) and Linux.Kernel.File.Clone.{Ficlone,CopyRange} (swift-linux-standard, Linux Kernel File Standard/Linux.Kernel.File.Clone.swift:85/132).
4. Affinity dispatch. Kernel.Thread.Affinity+Policy.swift:63 calls Linux.Thread.Affinity.apply(affinity) and :75 calls Windows.Kernel.Thread.Affinity.apply(affinity) — both platform surfaces are deleted by their owners per D2 (Delete the ISO-vocabulary-typed thread-affinity apply surface (hoist completion, D2) swift-linux#4, Split Windows.Kernel.File and Windows.Kernel.Thread into distinct policy namespaces (posix#1 mirror) swift-windows#2); kernel's new vocabulary can never satisfy them.

Proposed outcome

• Kernel Completion adds a dependency on Kernel Event (acyclic) and the Opcode file imports it; Equatable/Hashable synthesis compiles on all POSIX legs.
• The kqueue backend converts at the bridge boundary in both directions with typed-index retagging (.retag): every Kernel.Kqueue.Event construction passes Darwin.Kernel.Event.ID, every poll translation returns kernel's Kernel.Event.ID. No public vocabulary signature changes.
• Kernel.File.Clone+CrossPlatform.swift fully qualifies the platform mechanisms (Darwin.Kernel.File.Clone.Clonefile/.Copyfile; Linux.Kernel.File.Clone.Ficlone/.CopyRange) with per-file platform imports following the realized precedent in Kernel.Event.Source+Kqueue.swift.
• Kernel.Thread.Affinity+Policy.swift performs the kind-switch itself on every platform: .cores → Linux.Kernel.Thread.Affinity.setMask(cores:) / Windows.32.Kernel.Thread.Affinity.setMask(cores:); .numaNode → resolve node→cpus via the platform System.Topology.NUMA.discover() surface then setMask(cores:), .invalidNode on lookup failure — the exact bodies of the two deleted platform apply functions, relocated behind kernel's own typed-throw error mapping. Add the platform product/target dependencies these branches need; update the stale dispatch commentary in Sources/Kernel Thread/exports.swift:19.
• Typed-throws discipline unchanged throughout (per-operation leaf errors; no try? on typed-throwing callees).
• Observable: push-triggered full-tier CI at the landing head green on macOS/iOS/tvOS/watchOS/visionOS, Ubuntu 6.3 release, and Windows 6.3 debug (assertions leg unweakened), docs leg passing — the ruling's required fresh-build proof that no platform-L2 mechanism signature requires a unified vocabulary type. Residual nightly-only redness attributable centrally, named in a closing comment.

Sequencing

Wave 2. Depends on swift-foundations/swift-linux#4 and swift-foundations/swift-windows#2 on their mains. Companion: #5's residual (see its amendment comment) lands in the same push or immediately after; both close before swift-iso/swift-iso-9945#65 starts.

[coenttb]

Checkpoint — analysis complete, no code landed (session ended before implementation)

Working copy state: the shared workspace checkout of swift-kernel (not a scratch clone). git status clean, HEAD == origin/main == cf4875c. No uncommitted or untracked work exists — nothing to recover, nothing half-renamed. Only .build/ and the gitignored Package.resolved were refreshed (workspace package update).

Defect classes fixed: none. What follows is the full pre-implementation analysis so the successor does not have to redo it.

---

Local baseline (evidence)

macOS arm64, Swift 6.3.3, workspace package build after workspace package update. Resolved dependency heads at the time of the run: swift-posix a2c061a, swift-darwin 48fb2c3, swift-darwin-standard 2164b26, swift-linux 4f145df, swift-linux-standard 5f8d26b, swift-windows 0c09f42, swift-windows-32 332f49b, swift-iso-9945 f4fc61b.

Reproduced exactly the macOS-visible subset of this issue (D2/D3 kqueue + clone):

Sources/Kernel Event/Kernel.Event.Source+Kqueue.swift:66:33: error: cannot convert value of type
  'Kernel.Event.ID' (aka 'Tagged<POSIX.Kernel.Event, UInt>') to expected argument type
  'Darwin.Kernel.Event.ID' (aka 'Tagged<Darwin.Kernel.Event, UInt>')
Sources/Kernel Event/Kernel.Event.Source+Kqueue.swift:76:33: (same)
Sources/Kernel File/Kernel.File.Clone+CrossPlatform.swift:75:30:  error: cannot find 'Clonefile' in scope
Sources/Kernel File/Kernel.File.Clone+CrossPlatform.swift:134:30: error: cannot find 'Clonefile' in scope
Sources/Kernel File/Kernel.File.Clone+CrossPlatform.swift:145:21: error: cannot find 'Copyfile' in scope
Sources/Kernel File/Kernel.File.Clone+CrossPlatform.swift:211:21: error: cannot find 'Copyfile' in scope

Plus a pre-existing warning worth folding into the landing: Sources/Kernel File/Kernel.File.Copy.swift:12:8: warning: public import of 'Error_Primitives' was not used in public declarations or inlinable code.

Important: the build stops at Kernel Event / Kernel File, so the D1 Kernel Completion error is not yet observable locally on macOS — it will surface only after D2/D3 are fixed. Do not read its absence as "already fixed".

Gotcha for anyone building locally: a stale .build/checkouts/swift-posix predating a2c061a produces a completely misleading cascade of ambiguous type name 'Event' in 'Kernel' errors (the deleted POSIX.Kernel.Event typealias colliding with the hoisted Kernel.Event). Run workspace package update first. Package.resolved is gitignored in this repo, so updating is safe and leaves no dirty state.

---

D1 — Completion → Event visibility

• Payload site: Sources/Kernel Completion/Kernel.Completion.Submission.Opcode.swift:101, case readiness(events: Kernel.Event.Interest), already inside #if !os(Windows) with a documented IOCP rationale. Keep that gating; the fix is visibility only.
• Kernel Completion target deps are Kernel Core + Linux IO Uring + Windows Kernel File — no Kernel Event. Add "Kernel Event" to the target (unconditional is fine and acyclic: Kernel Event depends only on Kernel Core + primitives, and the Kernel umbrella already lists it unconditionally, so it builds on Windows).
• The import must be public import Kernel_Event (public position in a public enum payload) placed under #if !os(Windows) to match the case gating.

D2 — Kqueue ID retag

• Darwin.Kernel.Event.ID = Tagged<Darwin.Kernel.Event, UInt> (swift-darwin-standard, Darwin Kernel Event Standard/Darwin.Kernel.Event.Queue.swift:44); Kernel.Kqueue is ISO_9945.Kernel.Kqueue → Darwin.Kernel.Event.Queue.
• Only the two construction sites (66, 76) are broken. The poll direction at line 229 already retags correctly (raw.data.map { UInt(truncatingIfNeeded: $0) }.retag(Kernel.Event.self)) and produces kernel's Kernel.Event.ID — verify, don't rewrite.
• Tagged.retag (swift-tagged-primitives Tagged.swift:280) is public consuming func retag<New: ~Copyable & ~Escapable>(_: New.Type = New.self) -> Tagged<New, Underlying>. The type argument is defaulted, so Kernel.Event.ID(descriptor: fd).retag() infers New from the parameter type; the explicit .retag(Darwin.Kernel.Event.self) is preferable for readability but may need spelling as Darwin_Standard_Core.Darwin.Kernel.Event.self if plain Darwin collides with the system Darwin module in that target — the standard package itself writes extension Darwin_Standard_Core.Darwin.Kernel for exactly that reason. Try the short form first.
• Line 108 (Kernel.Kqueue.Event(id: .zero, ...)) is contextual and needs no change.

D3 — Bare Clone mechanisms

Post-re-anchoring homes confirmed on their mains:

kernel call site	qualified target	throws
Clonefile.attempt(source:destination:)	Darwin.Kernel.File.Clone.Clonefile.attempt	Darwin.Kernel.File.Clone.Error.Syscall
Copyfile.clone/.data	Darwin.Kernel.File.Clone.Copyfile.{clone,data}	Darwin.Kernel.File.Clone.Error.Syscall
Ficlone.attempt(source:destination:)	Linux.Kernel.File.Clone.Ficlone.attempt (typed form takes ISO_9945.Kernel.Descriptor)	Linux.Kernel.File.Clone.Error.Syscall
CopyRange.copy(source:destination:length:)	Linux.Kernel.File.Clone.CopyRange.copy	Linux.Kernel.File.Clone.Error.Syscall
Metadata.size(at:) (line 290, not listed in this issue but the same defect class)	Linux.Kernel.File.Clone.Metadata.size(at:)	Linux.Kernel.File.Clone.Error.Syscall

The qualification alone is not sufficient. Each platform now has a nominally distinct Error.Syscall and Error.Operation; the existing do throws(Kernel.File.Clone.Error.Syscall) blocks and Error(from: error) calls will not typecheck. A platform→kernel bridge is required:

• Darwin.Kernel.File.Clone.Error.Syscall = .platform(code:operation:) | .notSupported(operation:); its Operation has the full 8-case set (matches kernel's).
• Linux.Kernel.File.Clone.Error.Syscall = .platform(code:operation:) only (no .notSupported); its Operation has only 4 cases (statfs, stat, ficlone, copyFileRange).
• Kernel's own Kernel.File.Clone.Error.init(from:) / @_spi(Syscall) init(code:operation:) live in Kernel.File.Clone.Error+code.swift and are the right shape to delegate into.

Suggested placement (matches the "Platform Bindings" note already in Kernel.File.Clone.Error.swift): new Kernel.File.Clone.Error+Darwin.swift / +Linux.swift / +Windows.swift, each platform-gated, each declaring init(from syscall: <Platform>.Kernel.File.Clone.Error.Syscall) plus an Operation bridge.

The Windows branch of the same file also needs work and is not called out in the issue text: it calls Kernel.File.Copy.file(...) (see "Copy" below) which throws Windows.\32`.Kernel.File.Clone.Error.Syscall, and wraps it in an **untyped** do { } catch { }` — both the qualification and the typed-throws discipline need fixing there.

Per-file imports follow the Kernel.Event.Source+Kqueue.swift precedent (import Darwin_Kernel_Event_Standard with no declared product dep). Module names: Darwin_Kernel_Standard, Linux_Kernel_File_Standard, Windows_32_Kernel_File. No new package dependency is needed — all three modules are already in the transitive closure via Kernel Core's re-exports; adding a package dep would churn the gitignored Package.resolved.

D4 — Affinity dispatch

Exact bodies of the two deleted platform apply functions (recovered from swift-linux 4f145df^:Sources/Linux Kernel Thread/Linux.Thread.Affinity.swift and swift-windows 0c09f42^:Sources/Windows Kernel Thread/Windows.Kernel.Thread.Affinity.Apply.swift) — relocate these into Kernel.Thread.Affinity+Policy.swift:

• .cores(set) → Linux: Linux.Kernel.Thread.Affinity.setMask(tid: Int32 = 0, cores: Set<Int>) throwing Linux.Kernel.Thread.Affinity.Error (single case .platform(code)). Declared in swift-linux-standard, Linux Kernel System Standard/Linux.Kernel.Thread.Affinity.swift:54 — note it is in the System standard target, not the Thread one.
• .cores(set) → Windows: Windows.\32`.Kernel.Thread.Affinity.setMask(cores: Set)throwingWindows.`32`.Kernel.Thread.Affinity.Error(cases include.tooManyCPUsand.platform(.win32(...))). Declared in swift-windows-32, Windows 32 Kernel Thread/Windows.Kernel.Thread.Affinity+SetMask.swift:38`.
• .numaNode(id) → both platforms: System.Topology.NUMA.discover() → guard case .nonUniform(let nodes) = ..., let node = nodes.first(where: { $0.id == nodeID }) else throw .invalidNode(nodeID); then setMask(cores: node.cpus). Implementations: swift-linux-standard Linux Kernel System Standard/System.Topology.NUMA.Discover.swift:28; swift-windows-32 Windows 32 Kernel System/System.Topology.NUMA.Discover.swift:48.
• Darwin/other: throw .unsupported (unchanged).

Visibility is already satisfied without new deps (verified re-export chains):

• Linux: Kernel Core @_exporteds Linux_System and Linux_Kernel; both re-export Linux_Kernel_System_Standard, which declares both setMask and discover(). System_Primitives is @_exported by Kernel Core directly.
• Windows: Kernel Thread/exports.swift already @_exporteds Windows_Kernel_Thread, whose Windows.Kernel.Thread.swift @_exporteds Windows_32_Kernel (umbrella), which @_exporteds both Windows_32_Kernel_Thread (setMask) and Windows_32_Kernel_System (NUMA discover). swift-windows deliberately dropped its own Windows 32 Kernel System dep, but the umbrella still carries it.

Also update the now-stale dispatch commentary at Sources/Kernel Thread/exports.swift:19 (it still cites the deleted Windows.Kernel.Thread.Affinity.apply(_:) Phase 3/5 chain).

---

#5 residual

Kernel.File.Handle+Direct.swift. The four fileprivate var legacy converters (lines 53/68/80/90) can be deleted without losing the bridge: the delegated-to initializer Kernel.File.Handle.init(descriptor:direct:requirements:) fixes the contextual type, so the ISO values can be built with leading-dot member syntax (.direct / .uncached / .buffered, .known(.init(bufferAlignment:offsetAlignment:lengthMultiple:)), .unknown(reason: .platformUnsupported) …) inline in the initializer body — no ISO_9945 token anywhere. Kernel's and ISO's case/field sets match 1:1 (verified against ISO 9945 Core/Kernel.File.Handle.swift and kernel's Kernel.File.Direct.Requirements{,.Alignment}), and Alignment's three fields are all Memory.Alignment on both sides. Bonus: the same source then also compiles on Windows against Windows.\32`.Kernel.File.Handle`, since the contextual dots resolve per-platform.

Kernel.File.Copy.swift. The legacyCloneError / legacyCloneOperation converters (lines 200/227) exist only to feed Kernel.File.Copy.Error.clone(_:), whose payload on POSIX is ISO_9945.Kernel.File.Clone.Error. Hoisting Kernel.File.Copy into swift-kernel is NOT available: swift-posix a2c061a deleted only the four typealiases {Event, File.Clone, File.Direct, Thread.Affinity} — POSIX.Kernel.File.Copy = ISO_9945.Kernel.File.Copy (POSIX Kernel File/POSIX.Kernel.File.Copy.swift) is still live, so a kernel-side extension Kernel.File { enum Copy {} } would produce exactly the D1 ambiguity on POSIX, and swift-posix is out of scope for this task.
Recommended resolution, entirely inside kernel: drop the .clone(...) mapping and route the residual clone failures through .operation("clone failed: \(error)"). That is the pattern this very file already uses twice (.operation("stat failed: …") at :112, .operation("symlink create failed: …") at :291), it carries kernel's own Kernel.File.Clone.Error in the message, it yields zero ISO_9945 hits, and it stays valid after swift-iso/swift-iso-9945#65 deletes the ISO Clone.Error. The four semantic passthroughs (.sourceNotFound / .destinationExists / .permissionDenied / .isDirectory) already need no bridge.

After-grep target. grep -rn "ISO_9945" Sources currently returns 26 hits. Only 6 are load-bearing type references and all are in the two files above (Kernel.File.Handle+Direct.swift:53,68,80,90, Kernel.File.Copy.swift:202,229). Two more are live call sites that this issue does not scope and that must be preserved or separately routed: Kernel.File.Flush+CrossPlatform.POSIX.swift:37 (ISO_9945.Kernel.File.Flush.data) and Kernel.Thread.Local.swift:115 (internal typealias _PlatformSlot = ISO_9945.Kernel.Thread.Key), plus four uses in Kernel Terminal/Terminal.Mode.Raw.Token.swift (ISO_9945.Kernel.Termios.Attributes). The remaining ~12 are prose in comments. So "zero hits" as literally specified in the amendment requires either scoping the grep to the two named files, or additionally re-routing Flush/Local/Termios through POSIX-layer spellings and scrubbing comment prose — this is a genuine scope ambiguity in the amendment and should be adjudicated before the landing, not silently decided.

---

Windows-lane findings

Kernel.Thread.create / .yield. Exactly two call sites exist in kernel Sources, and they are in different targets — this is the non-obvious part:

• Sources/Kernel Thread/Kernel.Thread.spawn.swift:62 — try Kernel.Thread.create(body), inside @inlinable Kernel.Thread.Spawn.callAsFunction. Kernel.Thread.trap.swift reaches it indirectly via Kernel.Thread.spawn.
• Sources/Kernel Completion/Kernel.Completion.Notification+Wait.swift:47 — Kernel.Thread.yield(). The Kernel Completion target does not depend on Kernel Thread. It resolves Kernel.Thread purely through the platform namespace (POSIX.Kernel.Thread / Windows.Kernel.Thread). A forwarder placed in the Kernel Thread target will therefore not fix this site — either Kernel Completion gains a Kernel Thread dependency (that target is being touched anyway for D1's Kernel Event dep), or the call is qualified in place as Windows.\32`.Kernel.Thread.yield()under#if os(Windows)`.

The forwarding shim must be a real static func on Kernel.Thread under #if os(Windows) delegating to Windows.\32`.Kernel.Thread.{create,yield}; a typealiascannot forward a function, which is precisely the swift-windows finding. Note the@inlinableconstraint on thecreate caller — the shim needs matching visibility (@inlinable/@usableFromInline) or the caller must lose @inlinable`.

Kernel.File.Copy on Windows. Windows.Kernel.File is now a distinct empty enum whose per-member typealiases exclude Copy, so extension Kernel.File.Copy throughout Kernel.File.Copy.swift (unconditionally compiled) no longer resolves on Windows at all. Since hoisting is blocked (above), the coherent kernel-side fix is a Windows-only unifier alias:

#if os(Windows)
    extension Kernel.File { public typealias Copy = Windows.`32`.Kernel.File.Copy }
#endif

Windows.\32`.Kernel.File.Copyexists (swift-windows-32,Windows 32 Kernel File/Windows.Kernel.File.Copy.swift) and its Error/Optionsdeliberately mirror the ISO shapes case-for-case and field-for-field, so the shared algorithm inKernel.File.Copy.swiftcompiles against either. This also keepsKernel.File.Copy.file(source:destination:)— used by the Windows branch ofKernel.File.Clone+CrossPlatform.swift:193,241` — resolving.

---

Lint sweep

workspace package lint was run at cf4875c. The three try sites named in the brief are still present on main: Kernel.Thread.Local.swift:79 (try unsafe _PlatformSlot(destructor:)), Kernel.Thread.Handle+joinChecked.swift:34 (try join()), Kernel.Thread.Handle.Reference.swift:92 (try handle.join()). The rule bundle is Lint.Rule.Bundle.institute from swift-institute-linter-rules. The full findings list is dominated by Tests/Support/* (compound type name / minimal type body / untyped throws / try optional) — those are pre-existing and outside the touched-file set; the landing needs zero new findings on touched files, not a clean whole-repo sweep.

---

Recommended landing order for the successor

1. workspace package update (mandatory — see stale-checkout gotcha).
2. D2 (kqueue retag) + D3 (clone qualification + platform error bridges) — these are the only two macOS-verifiable classes; land them first and rebuild to expose D1.
3. D1 (Package.swift dep + public import Kernel_Event).
4. D4 (affinity kind-switch) — not locally verifiable on macOS beyond the #else branch; rely on CI.
5. Bridge the posix Handle boundary with kernel-vocabulary Direct opening #5 residual + Windows Copy alias + Kernel.Thread.create forwarder — likewise CI-verified.
6. Lint sweep on touched files, then push and dispatch gh workflow run ci.yml -R swift-foundations/swift-kernel.

Steps 4–6 are Windows/Linux-only compile paths; a macOS-green local build is necessary but far from sufficient, so budget for at least one CI round-trip.

[coenttb]

Landed — D1–D4 plus the #5 residual and the two windows-lane items

Head: 7b3cdd7 on main (two commits on cf4875c: 3a052aa then 7b3cdd7).
Push-triggered CI run: https://github.com/swift-foundations/swift-kernel/actions/runs/30625365398

Verification posture. macOS/Apple legs are the only thing that compiles on this machine; Windows and Linux legs are CI-verified only, not locally verified. Per the coordinator wind-down directive issued during this session, local builds were terminated machine-wide and the final exact-head local build was not completed — verification is CI-delegated. The strongest local evidence obtained is a fresh full build (workspace package build --package-path . --fresh, macOS arm64, Swift 6.3.3, exit 0, 3168 tasks, 321.74s, after a mandatory workspace package update) plus a green incremental build, both at a tree identical to 7b3cdd7 except for one reworded comment and one public import inside #if os(Windows). workspace package lint was run on that same tree.

---

D1 — Completion → Event visibility

Kernel Completion gains an unconditional "Kernel Event" target dependency (acyclic: Kernel Event depends only on Kernel Core plus primitives, and the umbrella already lists it unconditionally). Kernel.Completion.Submission.Opcode.swift gains public import Kernel_Event under #if !os(Windows), matching the gating on the readiness(events:) case. The IOCP rationale and the Windows gating of the case itself are unchanged.

Note for the record: this defect was not observable on macOS even after D2/D3 — the target's cached module predated the swift-posix change and SwiftPM did not invalidate it. Its absence from a macOS build is not evidence.

D2 — Kqueue ID retag

Kernel.Event.Source+Kqueue.swift: both kevent construction sites now pass Kernel.Event.ID(descriptor: fd).retag(), with the destination tag (Darwin.Kernel.Event.ID) inferred from the parameter type — the short form works, so no Darwin_Standard_Core. qualification was needed. The poll direction at the former line 229 already retagged correctly and is untouched, as was the contextual .zero at 108. No public vocabulary signature changed.

D3 — Bare clone mechanisms

Kernel.File.Clone+CrossPlatform.swift now spells all five mechanisms at their qualified L2 homes: Darwin.Kernel.File.Clone.{Clonefile,Copyfile}, Linux.Kernel.File.Clone.{Ficlone,CopyRange,Metadata} (Metadata.size(at:) was the unlisted member of the same class). Per-file imports (Darwin_Kernel_Standard, Linux_Kernel_File_Standard) follow the Kernel.Event.Source+Kqueue.swift precedent — no new package dependency, so no Package.resolved churn.

As the checkpoint predicted, qualification alone does not typecheck, because each platform now throws a nominally distinct Error.Syscall. Three new platform-binding files carry the bridge:

• Kernel.File.Clone.Error+Darwin.swift — .notSupported/.platform plus the eight-member Operation transliteration, delegating the code classification to kernel's existing POSIX init(code:operation:).
• Kernel.File.Clone.Error+Linux.swift — .platform only, widening the four-member Linux Operation set into kernel's eight.
• Kernel.File.Clone.Error+Windows.swift — Win32 codes are not POSIX codes, so this one delegates the semantic classification to its owner (Windows.\32`.Kernel.File.Clone.Error.init(from:)`) and transliterates only the resulting semantic case.

The Windows branch of the clone fallback also loses its untyped do { } catch { } in favour of do throws(Windows.\32`.Kernel.File.Clone.Error.Syscall)`.

D4 — Affinity dispatch

Kernel.Thread.Affinity+Policy.swift performs the kind-switch itself on every platform. .cores → pin(to:); .numaNode → cpus(of:) then pin(to:). pin(to:) calls Linux.Kernel.Thread.Affinity.setMask(cores:) / Windows.\32`.Kernel.Thread.Affinity.setMask(cores:)behind kernel's own typed error mapping (Linux's single.platformcase; Windows's four, including.tooManyCPUs); cpus(of:)resolves the node throughSystem.Topology.NUMA.discover()and throws.invalidNodeon lookup failure. Darwin keeps.unsupported. Visibility needed no new package dependency, only per-file imports. The stale dispatch commentary in Sources/Kernel Thread/exports.swift` is rewritten.

#5 residual (per amendment 5141147859 and adjudication 5141567869)

• Kernel.File.Handle+Direct.swift: the four legacy converters are deleted. The delegated-to platform initializer pins the contextual type, so every platform value is a leading-dot member and the file names no platform vocabulary — which also makes the same source valid on Windows. One necessary adjustment the checkpoint did not anticipate: the kernel-vocabulary entry point had to take mode: rather than direct:, because with identical labels it overloads the initializer it delegates to and every leading-dot argument stays viable for both candidates (ambiguous use of 'sectorSizeUndetermined' / 'init(bufferAlignment:offsetAlignment:lengthMultiple:)'). Kernel.File.Open.open updated accordingly; it is the only call site.
• Kernel.File.Copy.swift: legacyCloneError / legacyCloneOperation deleted; residual clone failures route through .operation("clone failed: \(error)") per the adjudication, carrying kernel's own Kernel.File.Clone.Error in the message. The four semantic passthroughs are unchanged. The now-internal-only Error_Primitives import was demoted from public (clearing the pre-existing unused-public-import warning).
• After-grep evidence, scoped to the two named files per the adjudication:

  $ /usr/bin/grep -rn "ISO_9945" "Sources/Kernel File/Kernel.File.Handle+Direct.swift" "Sources/Kernel File/Kernel.File.Copy.swift"
  $ echo $?
  1
  

  Zero hits, including comment prose. Positive control on the same instrument and the same files: grep -c "Kernel" Kernel.File.Copy.swift → 35. The out-of-scope live references (Kernel.File.Flush+CrossPlatform.POSIX.swift, Kernel.Thread.Local.swift, Kernel Terminal/Terminal.Mode.Raw.Token.swift) are untouched, as adjudicated.

Windows-lane items (swift-foundations/swift-windows#2 comment 5141323361)

• Kernel.Thread+Windows.swift (new): real @inlinable static func create(_:) / yield() forwarders to Windows.\32`.Kernel.Thread, since the distinct policy enum's per-member typealiases can only carry types. Correction to the checkpoint's reading: the second call site, Kernel.Completion.Notification+Wait.swift:47, sits inside a whole-file #if !os(Windows), so it never needed a Windows resolution and Kernel Completiondid **not** need aKernel Threadedge. An unfiltered grep ofSourcesconfirms these are the only twoKernel.Thread.create/.yield` sites.
• Kernel.File.Copy+Windows.swift (new): extension Kernel.File { public typealias Copy = Windows.\32`.Kernel.File.Copy }under#if os(Windows), with the rationale that hoisting is blocked while POSIX.Kernel.File.Copyis live. This also keepsKernel.File.Copy.file(source:destination:)` resolving for the Windows clone branches.

---

Lint

workspace package lint (bundle Lint.Rule.Bundle.institute, 93 rules, 165 files, all advisory) reports 265 violations, dominated by pre-existing Tests/Support/* findings. On the touched set, every finding maps to a line I did not write (Kernel.Event.Source+Kqueue.swift 101/108/230; Kernel.File.Copy.swift 226/227, renumbered by the deletion) except two new ones, both on Kernel.File.Copy+Windows.swift:31 and both explicitly framed by their own rule text as review prompts rather than defects:

• [API-NAME-004a] namespace adoption typealias — asks whether the higher layer declares ≥5 siblings on the adopted concept. It does: Kernel.File.Copy.swift declares copy plus five private helpers on it.
• [PLAT-ARCH-018] typealiased namespace bridge — asks that the foreign path be grepped for collisions before adding sub-types through the alias. Kernel adds only methods under Kernel.File.Copy, no sub-types.

I left both unsuppressed deliberately: the repository already carries eight identical unsuppressed pairs for the same L3-unifier shape in Sources/Kernel/Exports.swift, and silencing a review prompt is the failure mode the rule exists to prevent. Flagging here rather than in the source is the honest disposition; happy to be overruled either way.

Not done / for the follow-up

• No local Windows or Linux compile exists for D3's error bridges, D4's dispatch, the Windows create/yield forwarders, or the Kernel.File.Copy alias. Those four are the highest-risk parts of this landing and the run above is their first real test. The most likely failure mode is per-file member visibility through an @_exported chain rather than logic.
• Both files deleted-in-spirit by Purge Windows branches, relocate platform constants, and delete the hoisted vocabulary families swift-iso/swift-iso-9945#65 (Kernel.File.Handle+Direct.swift's transliteration and Kernel.File.Copy+Windows.swift) carry an explicit note to delete them once their blocking condition clears.

[coenttb]

Routing record: swift-products#1 divergence report — same defect classes, already landed

Coordinator routed swift-foundations/swift-products#1 (comment 5143102245) here for filing or fold-in. Disposition: fold — no new issue. Every reported error class maps onto work this issue and #5 already landed:

• Kernel.Event.Source+Epoll.swift 'Poll'/'Descriptor' is not a member type of 'Linux_Kernel.Kernel.Event' → the stale mechanism spellings requalified in dd61339/41cd15f (Bridge the posix Handle boundary with kernel-vocabulary Direct opening #5 thread).
• Kernel.File.Clone+CrossPlatform.swift cannot find 'Ficlone'/'CopyRange', Metadata drift → D3, landed in 7b3cdd7.
• Kernel.File.Copy.swift / Kernel.File.Open.swift POSIX.Kernel.File.* vs ISO_9945.Kernel.File.* mismatches → the Bridge the posix Handle boundary with kernel-vocabulary Direct opening #5 residual (legacy converters deleted, kernel-vocabulary end-to-end), landed in 7b3cdd7.

Timeline evidence: the products run underlying that diagnosis (30607844717) was created 2026-07-31T05:49Z and built swift-kernel at pre-fix main (cf4875c era); the first fix landed at 10:58Z. On current main, full-tier run 30630099158 (head 64a7067) is green on Ubuntu (Swift 6.3, release) — the exact leg that failed for swift-products — and ef4610f has since fixed the Windows leg (#7).

Action for the products lane: rerun against a fresh resolution of swift-kernel main (re-resolve if the checkout pinned a pre-fix revision). Noted on swift-products#1.

[coenttb]

Claiming this issue — dispatched by the successor Institute coordinator session. Dispatching a fresh full-tier CI workflow_dispatch on main (head ef4610f) to produce the missing evidence run (prior run 30632022105 was cancelled and is void).

[coenttb]

Full-tier CI run https://github.com/swift-foundations/swift-kernel/actions/runs/30637005244 (head ef4610f, workflow_dispatch) result:

• macOS/iOS/tvOS/watchOS/visionOS (Swift 6.3, debug) — success
• Ubuntu (Swift 6.3, release) — success
• Ubuntu (Swift main nightly, release) — failure
• Ubuntu (Swift 6.4.x nightly, release) — failure
• Windows (Swift 6.3, debug) — cancelled: the Test step ran ~44 minutes (14:05:30Z–14:49:17Z) without completing, then was force-cancelled with orphaned swift-frontend/swiftc processes reaped on cleanup. This is a hang, not a clean pass or a clean failure.

The two nightly Ubuntu legs are the known central redness (swift-institute/Issues#87 — SILGen assertion on 6.4-dev/6.5-dev toolchains only; 6.3.3 release compiles clean per that issue's own reproduction matrix) and do not block this issue per the recorded disposition.

The Windows (Swift 6.3, debug) leg is not covered by #87 — that crash is nightly-toolchain-only, and this leg runs the 6.3 release toolchain. This issue's own closure bar (see body) explicitly requires "Windows 6.3 debug (assertions leg unweakened)" green. It is not green: it hung and was cancelled. Not closing #6 — recording the leg result on the owning issue (#7) and stopping per the gating-leg-red instruction.

[coenttb]

Claiming the Windows 6.3 Test-step hang forensics on this issue — forensic lane dispatched by coordinator session 397aa396-7a15-446a-85c9-771f93b52651. Scope: characterize the hang on run https://github.com/swift-foundations/swift-kernel/actions/runs/30637005244 (Windows, Swift 6.3, debug) from CI logs and file a disposition here. Not closing this issue.

[coenttb]

Forensic disposition: Windows 6.3 Test-step hang, run 30637005244

Forensic lane for coordinator session 397aa396-7a15-446a-85c9-771f93b52651. Evidence: full job log of ci / matrix / Windows (Swift 6.3, debug) (job 91177145245) on https://github.com/swift-foundations/swift-kernel/actions/runs/30637005244, head ef4610f, plus the manifest and source at that revision. Log analysis only; no re-dispatch was needed.

Characterization

No test ever ran, and no test hung. The Test step's build progressed normally through ~3,525 compile tasks and failed at 14:17:24Z with a deterministic compile error:

[3518/3539] Emitting module _Lock_Test_Process
D:\a\swift-kernel\swift-kernel\Tests\Support\_Lock Test Process\main.swift:33:23:
error: no such module 'POSIX_Kernel_Descriptor'
error: emit-module command failed with exit code 1

After that diagnostic the job emitted zero further output for ~32 minutes (14:17:24Z → 14:49:17Z force-cancel), and cleanup reaped orphaned swift-frontend/swiftc processes. So the observed "44-minute Test hang" decomposes into two independent facts:

1. Kernel source defect (primary, deterministic, Windows-only). Package.swift declares the _Lock Test Process executable's POSIX Kernel Descriptor dependency with condition: .when(platforms: [.macOS, .iOS, .tvOS, .watchOS, .visionOS, .linux]) — Windows excluded — but Tests/Support/_Lock Test Process/main.swift:33 imports it unconditionally: @_spi(Syscall) import POSIX_Kernel_Descriptor. On Windows the module does not exist, so the target can never compile. An unfiltered grep of the file shows the import is its only reference to the module (lines 422/430 are comments); the rest of the file already carries #if os(Windows)/WinSDK branches, so the target is intended to build there. This is kernel source, not CI infrastructure, not the 6.3 release toolchain's codegen, and not SILGen assertion: mutating method through a nonmutating _modify member whose base is a mutating _read yield swift-institute/Issues#87 (that assertion is 6.4-dev/6.5-dev nightly SILGen; this leg's toolchain is swift-6.3.3-RELEASE and it produced an ordinary diagnostic, not a crash). It will reproduce on every Windows dispatch until fixed; Apple/Linux legs never see it because the conditional dependency satisfies the import there.

2. Hang-on-failure (secondary, toolchain behavior). After emitting the error, the SwiftPM build process on Windows failed to terminate — silent for 32 minutes with orphaned frontend processes, converting what should have been a clean red into a timeout/cancel. This is a suspected Windows Swift 6.3 build-system teardown defect, but it is only reached via defect (1), it cannot be isolated or reproduced from this macOS machine, and fixing (1) removes the trigger. Per toolchain-defect discipline I am not filing a swift-institute/Issues reproducer on this evidence: no isolated reproducer exists, only a production-shape observation.

Disposition and next owner

• Kernel source fix (next owner: this issue's implementation lane): delete the @_spi(Syscall) import POSIX_Kernel_Descriptor line from Tests/Support/_Lock Test Process/main.swift (it is unused), or gate it to the platforms that declare the dependency if a future use is intended. Closure evidence for Complete the hoist inside kernel: Completion imports, platform-bridge retags, affinity dispatch (D1/D2) #6 remains a fresh full-tier workflow_dispatch with the Windows 6.3 debug leg green.
• Conditional toolchain escalation (owner: coordinator): if a post-fix Windows 6.3 leg hangs again after a clean failure or during tests, that is independent evidence of the teardown defect and warrants a reproducer decision then. Upstream filing stays principal-gated; no upstream action recommended now.

Not closing #6; its closure bar (green Windows 6.3) remains unmet.

[coenttb]

Claiming this issue — implementation lane dispatched by coordinator session 397aa396-7a15-446a-85c9-771f93b52651 (supersedes the forensic claim in comment 5144242570 from the same coordinator session). Scope: fix the Windows compile defect diagnosed in #6 (comment), dispatch a fresh full-tier workflow_dispatch on main, and close on green including the Windows 6.3 leg.

[coenttb]

Implementation lane result: import fix landed and verified; Windows leg blocked by a deeper pre-existing defect — stopping

Implementation lane for coordinator session 397aa396-7a15-446a-85c9-771f93b52651 (claim: comment 5144300413).

Landed

Commit 0ff2900 on main (single commit on ef4610f, pathspec-scoped, committed-tree read back): gates @_spi(Syscall) import POSIX_Kernel_Descriptor in Tests/Support/_Lock Test Process/main.swift behind #if !os(Windows), matching the manifest's platform condition. Deletion was wrong — contrary to the forensic disposition (comment 5144258820), the import is used on POSIX: Kernel.Descriptor(_rawValue:) at the POSIX main() is the @_spi(Syscall) initializer on ISO_9945.Kernel.Descriptor, visible only through this import (POSIX_Kernel_Descriptor re-exports ISO_9945_Core with @_exported @_spi(Syscall)). A local macOS workspace package build --jobs 4 at 0ff2900 is green (iteration signal only).

Evidence run

Fresh full-tier workflow_dispatch at head 0ff2900: https://github.com/swift-foundations/swift-kernel/actions/runs/30641978987

• All Apple legs, Ubuntu 6.3 release, and every lint/advisory gate — success.
• Ubuntu nightly (main, 6.4.x) — failure: the known SILGen assertion: mutating method through a nonmutating _modify member whose base is a mutating _read yield swift-institute/Issues#87 SILGen nightly redness; non-gating per the recorded disposition on this thread.
• Windows (Swift 6.3, debug) — cancelled again, but for a new reason: the no such module 'POSIX_Kernel_Descriptor' error is gone (fix confirmed effective). The build now reaches the helper's Windows branch and fails with pre-existing compile errors (job 91194058361, 15:28:48Z).

The unmasked defect (new, out of this lane's scope)

main.swift's #else (Windows) branch is written against a lock API that does not exist on Windows:

• Kernel.Lock resolves to Windows.32.Kernel.Lock, which declares only Acquire (try/wait/deadline) and a 3-case Error (contention/deadlock/unavailable) — no Kind, no Token, no Range, no timedOut/interrupted/invalidRange/platform cases (swift-windows-32, Windows 32 Kernel Core). L3 Windows.Kernel.Lock is a bare typealias to that L2 enum.
• Windows.Kernel.Descriptor.init is _rawValue: UInt, not rawValue: HANDLE.

So a green Windows leg requires either implementing a Windows Token/Kind/Range lock surface (feature work in swift-windows-32 / swift-windows — different repositories) or redesigning the helper's Windows branch against the raw Win32 surface. That is design work beyond the diagnosed import defect this lane was dispatched to fix.

Hang-on-failure recurred

After the compile diagnostics (15:28:48Z) the job emitted nothing for ~31 minutes until force-cancel (15:59:47Z), with an orphaned swift-frontend reaped on cleanup — second independent observation of the Windows 6.3 SwiftPM teardown hang, now at a different failure site. Reporting per the recurrence condition; escalation owner is the coordinator.

State

• Complete the hoist inside kernel: Completion imports, platform-bridge retags, affinity dispatch (D1/D2) #6 stays open; its closure bar (green Windows 6.3) remains unmet.
• Removing the assignee: work is stopping without closure. Next owner needs scope over swift-windows-32/swift-windows lock surface design (route via coordinator).