coilyco-flight-deck/umbra

Watch

Implement blocking file locks on Windows #262

New issue

Closed

opened 2026-07-28 00:36:12 +00:00 by coilyco-ops · 1 comment

coilyco-ops commented

2026-07-28 00:36:12 +00:00

Member

Ward's native Windows suite exposed that cli-guard/pkg/flock intentionally degrades Exclusive and Unlock to no-ops on non-Unix builds. Ward uses those calls for issue-scoped and repo-scoped launch reservation locks, so concurrent Windows directors can both pass the same launch gate.

Evidence:

cli-guard v0.113.0 pkg/flock/flock_other.go returns nil from both operations.
Ward's serialization test acquires the same lock twice concurrently on Windows instead of blocking.
Ward's Windows repair keeps the test skipped with an explicit dependency note so the suite does not claim serialization that cli-guard cannot provide.

Acceptance:

pkg/flock implements blocking exclusive whole-file locking and unlock on Windows.
Two file handles for the same path serialize across goroutines and processes.
Closing a locked handle releases the lock.
Unix flock behavior remains unchanged.
Ward can remove its Windows skip and pass the reservation serialization test.
cli-guard and Ward validation pass on Windows and Unix.

Ward's native Windows suite exposed that `cli-guard/pkg/flock` intentionally degrades `Exclusive` and `Unlock` to no-ops on non-Unix builds. Ward uses those calls for issue-scoped and repo-scoped launch reservation locks, so concurrent Windows directors can both pass the same launch gate. Evidence: * cli-guard v0.113.0 `pkg/flock/flock_other.go` returns nil from both operations. * Ward's serialization test acquires the same lock twice concurrently on Windows instead of blocking. * Ward's Windows repair keeps the test skipped with an explicit dependency note so the suite does not claim serialization that cli-guard cannot provide. Acceptance: * `pkg/flock` implements blocking exclusive whole-file locking and unlock on Windows. * Two file handles for the same path serialize across goroutines and processes. * Closing a locked handle releases the lock. * Unix flock behavior remains unchanged. * Ward can remove its Windows skip and pass the reservation serialization test. * cli-guard and Ward validation pass on Windows and Unix.

coilyco-ops added the

autonomy

async-consult

priority

labels

2026-07-29 03:45:33 +00:00

coilyco-ops added

priority

and removed

priority

labels

2026-07-29 06:27:44 +00:00

coilyco-ops added

and removed

labels

2026-08-17 01:42:39 +00:00

coilyco-ops commented

2026-08-17 01:55:47 +00:00

Author

Member

Decision recorded by Darren (director seat), 2026-08-16, from a full triage pass. Kai's call in a consult round. Closing as declined.

The call

Kai's words, verbatim:

remove any and every feature that needs fiddle cross platform variance

Windows blocking file locks will not be built. Every acceptance criterion in this issue is declined, including the one asking Ward to remove its skip and pass the reservation serialization test. Ward's skip becomes permanent.

What was rejected, and why

Build it. This was the recommended option and Kai declined it. It would have needed a real Windows host to verify, and it buys serialization on a platform this estate barely runs agents on, at the cost of carrying a second locking implementation forever.
Declare Windows unsupported and leave the no-op in place, documented. Also declined, and it is worth saying why the middle option is not the answer: the defect this issue reports is not that Windows lacks locking, it is that Exclusive and Unlock return nil, so a caller cannot distinguish a held lock from a no-op. Documenting a silent lie leaves the lie.

What follows from the call, filed separately

Kai's scoping answer was "flock now, sweep the rest separately", so two issues rather than one rescope of this one:

#301 - pkg/flock non-Unix returns success without locking. Remove the silent degradation so a non-Unix build fails loudly at the call rather than succeeding falsely.
#302 - inventory every other silently-degrading platform variant in umbra and decide each. The known one is the sandbox, which #261 already records as degrading to unsandboxed off Linux while the surrounding claims do not say so.

Both are narrower and more honest than this issue's ask, which is why this closes rather than being retitled: the request here was to implement Windows locking, and that request is refused.

Downstream

Ward's serialization test stays skipped, and its dependency note should be updated to point at this decision rather than at a pending implementation. Two concurrent Windows directors will both pass the same launch reservation gate, which is now a stated property rather than an outstanding bug.

**Decision recorded by Darren (director seat), 2026-08-16, from a full triage pass. Kai's call in a consult round. Closing as declined.** ## The call Kai's words, verbatim: > remove any and every feature that needs fiddle cross platform variance **Windows blocking file locks will not be built.** Every acceptance criterion in this issue is declined, including the one asking Ward to remove its skip and pass the reservation serialization test. Ward's skip becomes permanent. ## What was rejected, and why * **Build it.** This was the recommended option and Kai declined it. It would have needed a real Windows host to verify, and it buys serialization on a platform this estate barely runs agents on, at the cost of carrying a second locking implementation forever. * **Declare Windows unsupported and leave the no-op in place, documented.** Also declined, and it is worth saying why the middle option is not the answer: the defect this issue reports is not that Windows lacks locking, it is that `Exclusive` and `Unlock` **return nil**, so a caller cannot distinguish a held lock from a no-op. Documenting a silent lie leaves the lie. ## What follows from the call, filed separately Kai's scoping answer was "flock now, sweep the rest separately", so two issues rather than one rescope of this one: * **#301** - `pkg/flock` non-Unix returns success without locking. Remove the silent degradation so a non-Unix build fails loudly at the call rather than succeeding falsely. * **#302** - inventory every other silently-degrading platform variant in umbra and decide each. The known one is the sandbox, which #261 already records as degrading to unsandboxed off Linux while the surrounding claims do not say so. Both are narrower and more honest than this issue's ask, which is why this closes rather than being retitled: the request here was to implement Windows locking, and that request is refused. ## Downstream Ward's serialization test stays skipped, and its dependency note should be updated to point at this decision rather than at a pending implementation. Two concurrent Windows directors will both pass the same launch reservation gate, which is now a stated property rather than an outstanding bug.

coilyco-ops referenced this issue

2026-08-17 01:56:07 +00:00

pkg/flock returns success without locking on non-Unix, so a caller cannot tell a held lock from a no-op #301

coilyco-ops referenced this issue

2026-08-17 01:56:29 +00:00

Inventory every silently-degrading platform variant, and remove the silence from each #302

coilyco-ops closed this issue

2026-08-17 01:56:56 +00:00

coilyco-ops referenced this issue from a commit

2026-08-17 02:46:18 +00:00

fix(flock): refuse on non-unix instead of returning a silent no-op