feat(guard): hand-woven concurrency gates are held at zero in production and ratcheted in tests by rbuergi · Pull Request #2782 · Systemorph/MeshWeaver

rbuergi · 2026-08-30T13:54:05Z

AGENTS.md states the rule — a SemaphoreSlim or any hand-rolled gate is forbidden outside the one sealed inside IoPool — and nothing enforced it. This is the conservative half of the sweep: freeze the debt, so the wave that clears it can be written without the count moving underneath.

Two tiers, the shape #2762 established

ProductionRoots (src, tools, samples, clients, memex) — ZERO, no allow file. The only permitted gates are SanctionedGates entries, verified not listed: each must still exist and still contain a gate, so an entry cannot outlive its subject.
RatchetedRoots (test) — a seeded inventory that may only shrink. Measured on main's tip: 79 sites across 24 files, every one a ManualResetEventSlim, 30 of them in IoPoolTest.cs.

🚨 It found a production violation on its first run

tools/MeshWeaver.ThumbnailGenerator — which my earlier src/-only grep had missed, and which I had reported to the maintainer as "production is clean". It is not; that report was scoped too narrowly.

Registered rather than converted, with the premise verified rather than asserted in prose. Its csproj is an Exe referencing Microsoft.Playwright, SixLabors.ImageSharp and System.CommandLine — not one MeshWeaver assembly. There is no hub, no grain turn and no IIoPool in that process, so the defect the rule prevents cannot occur; its semaphore bounds concurrent browser pages against an external server.

The register re-reads that csproj on every run and fails if a MeshWeaver ProjectReference ever appears. An exemption whose premise silently stops holding is worse than one whose subject moved — the subject's absence at least fails loudly. And tools stays in scope rather than being dropped, so a gate added to a tool that does reference the mesh still fails.

Why the test tree is in scope at all

In a test the same primitive fails more subtly: it strands a blocked worker when an assertion throws before the release runs. Measured today on #2770 — IoPoolResidualNamesItsPoolTest put release.Set() after an await of the method-timeout token, so on timeout the release never ran and the leaf held a pool thread for two minutes, into the next test.

Proven by breaking it, not by passing

The self-test plants a real directory tree and runs the real scan over it — .cs, .csx, a prose mention, a string literal and bin/ — rather than matching the regex against strings. That distinction is exactly the defect found in three separate guards in this repo today: a self-test that never calls its own scanner can lose half its scope and stay green.

Then each arm was mutated:

probe	result
a new gate in `src/`	🔴 production zero
a new file in `test/` outside the allow list	🔴 NEW SITE
a listed test file's count grows	🔴 may only shrink
all restored	🟢 4/4

What this deliberately does NOT do

It does not convert the 79 test sites. That is a 24-file change with real deadlock-shaped subtleties in each one, and it wants its own review — the .ToTask() programme worked precisely because the ratchet landed first and the sweep followed against a frozen number.

🤖 Generated with Claude Code

…ion and ratcheted in tests A SemaphoreSlim / ManualResetEventSlim / AutoResetEvent / CountdownEvent / Monitor.Wait parks a thread. On a hub action block or a grain turn that is the deadlock the mesh cannot recover from — the class /async names alongside await on a hub. AGENTS.md states the rule; nothing enforced it. Two tiers, the shape #2762 established: - ProductionRoots (src, tools, samples, clients, memex) — ZERO, no allow file. The only permitted gates are SanctionedGates entries, VERIFIED not listed: each must still exist and still contain a gate, so an entry cannot outlive its subject. - RatchetedRoots (test) — a seeded inventory that may only shrink. Measured on main's tip: 79 sites across 24 files, every one a ManualResetEventSlim, 30 of them in IoPoolTest.cs. TotalBudget 79. 🚨 The guard found a production violation on its first run that a src/-only grep had missed: tools/MeshWeaver.ThumbnailGenerator. Registered rather than converted, with the premise VERIFIED rather than asserted in prose — its csproj is an Exe referencing Microsoft.Playwright, SixLabors.ImageSharp and System.CommandLine and NOT ONE MeshWeaver assembly, so there is no hub, no grain turn and no IIoPool in that process and the defect cannot occur. The register re-reads that csproj on every run and FAILS if a MeshWeaver ProjectReference ever appears: an exemption whose PREMISE silently stops holding is worse than one whose subject moved, because the subject's absence at least fails loudly. `tools` stays in scope rather than being dropped, so a gate added to a tool that DOES reference the mesh still fails. The self-test plants a real tree and runs the REAL scan over it — .cs, .csx, prose, a string literal and bin/ — rather than matching the regex against strings. That distinction is the defect this repo found in three separate guards today. Verified by MUTATION, each arm proven able to fail and then restored: A new gate in src/ -> RED (production zero) A new file in test/ not in the allow list -> RED (NEW SITE) A listed test file's count grows -> RED (may only shrink) restored -> GREEN 4/4 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Copilot

Pull request overview

Adds a governance ratchet to enforce the “no hand-woven concurrency gates” rule: production roots must stay at zero (except a verified sanctioned register), while the test tree is held to a seeded inventory that may only shrink.

Changes:

Introduces HandWovenGateRatchetGuard to scan production/test roots for gate primitives and enforce the zero/ratchet policy.
Adds a seeded allow file enumerating current test-tree gate sites/counts.
Adds a “What’s New” documentation entry describing the new enforcement.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
test/MeshWeaver.Documentation.Test/HandWovenGateRatchetGuard.cs	New ratchet guard test enforcing zero-in-production and shrink-only-in-tests scanning policy.
test/HandWovenGateSites.allow	Seeded inventory of current test-tree gate sites and counts for the ratchet to enforce.
src/MeshWeaver.Documentation/Data/WhatsNew/2026-08-30-hand-woven-concurrency-gates-cannot-come-back.md	User-facing documentation entry announcing the new guard/ratchet behavior.

Suppressed comments (1)

test/MeshWeaver.Documentation.Test/HandWovenGateRatchetGuard.cs:146

Like the production scan, this test relies on SourceScan.SourceFiles, which silently ignores missing roots. If the "test" root is renamed/moved, the guard will stop scanning and can pass vacuously. Add an explicit existence assertion for RatchetedRoots.

        var root = SourceScan.FindRepoRoot();
        var allowed = SourceScan.ReadAllowFile(
            Path.Combine(root, "test", AllowFileName), AllowFileName);

        var actual = SourceScan.SourceFiles(root, RatchetedRoots)

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

+///   <item><see cref="RatchetedRoots"/> — <c>test/</c> carries a seeded inventory that may only
+///   SHRINK. Measured 2026-08-30: 79 sites across 27 files, every one a
+///   <c>ManualResetEventSlim</c>, 30 of them in <c>IoPoolTest.cs</c>. The sweep lands in a later
+///   wave; this freezes the debt so it cannot grow while that wave is written. When it empties,


+        var root = SourceScan.FindRepoRoot();
+        var sanctioned = SanctionedGates.Select(s => s.File).ToHashSet(StringComparer.Ordinal);
+


github-actions · 2026-08-30T14:00:40Z