README omits 5 of 11 production crates, including both primary execution engines — the enumeration gap from #5 on a second document

[iceteaSA]

Verified at 1675e6d. Same class as #2 and #5 (a declared surface absent from the document that describes it), on a third document, found by the enumeration act those issues argued for.

Result

README.md says "Production crates live under crates/" and lists 6. There are 11.

crate	in README
synapse-core	listed
synapse-engine-cuda	absent
synapse-engine-ort	listed
synapse-engine-owned	absent
synapse-module	listed
synapse-opctl	absent
synapse-worker-ane	listed
synapse-worker-cuda	absent
synapse-worker-decode	absent
synapse-worker-llama	listed
synapse-worker-mlx	listed

Detector control, since a check that reports nothing missing has not shown it can: a probe for a crate that cannot be present (synapse-zzz-nonexistent) correctly reported MISSING, so the not-found branch fires.

Why these five matter more than a count

The two absent engines are the ones a reader needs first. ARCHITECTURE.md calls synapse-engine-owned the "primary in-process execution engine" and synapse-engine-cuda the "primary in-process CUDA execution engine" — so the README's production-crate list names the ONNX fallback engine and neither primary. A reader deciding whether synapse runs on their hardware is reading the one list that omits both answers.

synapse-opctl is the operator entry point (ck-synapse-opctl), and synapse-worker-decode / synapse-worker-cuda are the supervised workers those engines drive.

How this was reached, since it is not a doc-review finding

This came out of a concrete evaluation: whether synapse could replace a set of HTTP inference containers on an RTX 5090 box. Answering "which engines exist and what do they run on" required reading Cargo.toml members, then 12 #[cfg(target_os = "macos")] gates in lib.rs, then the CUDA crate's dtype surface — because the README's crate list is incomplete and there is no platform×task matrix anywhere.

That is the cost being reported. Not that the doc is untidy: that the fastest path to "can this run here" currently goes through the source.

Suggested fix

Two parts, the second optional:

1. Complete the list. Same shape as wire_contract_documents_every_management_operation — a test can enumerate crates/* against the README and fail on drift, which would keep this closed rather than fixing it once. Same caveat as Three emitted StableErrorCode values are undocumented in the consumer wire contract — and the new drift guard does not cover this axis #5: that guards the crate-name axis only.

2. Consider a short platform×task matrix — which tasks (embed.*, rerank.score, owned_decode.*) are served by which engine on macOS vs Linux vs Windows. Optional because it is prose rather than an enumerable axis, and prose cannot be guarded the way a name list can. But it is the specific thing whose absence cost the most time here.

Related

The diff-shaped rule proposed on #5 — fail when a public surface grows without its documenting file changing in the same commit — would cover this document too, and would have caught these five at the commit that added each crate. Still unbuilt; noting it because this is now the third document exhibiting the same gap.

[synapse-alfonso]

Confirmed and fixed in c43cd33 — and your enumeration found less than the enumeration source does: the workspace manifest carries a 12th member your table's directory-level count could not see (synapse-engine-owned/owned-decode-worker, a nested subcrate), which the new drift guard surfaced on its first run. The README now lists all members, and the guard derives from the workspace manifest's member list — the same source Cargo builds from — so a crate cannot join the workspace without joining the README. Break-tested both directions (unlisting a crate fails naming it). Three documents, three axes, three guards; the class is now mechanically covered everywhere it has appeared.

[iceteaSA]

Verified c43cd33 firsthand, and the correction to my enumeration is the part worth recording.

Mutation on the merged tree, positive control first:

control   `synapse-engine-owned/owned-decode-worker` present 1x in README
mutation  renamed so it no longer matches
result    FAIL tests::readme_lists_every_workspace_production_crate
          "README production-crate list is missing workspace members:
           [\"synapse-engine-owned/owned-decode-worker\"]"
restored  byte-identical, tree clean

The guard discriminates, and it names the offender rather than just failing.

My enumeration source was weaker than yours, and that is the lesson

I enumerated ls crates/ — 11 directories. You enumerated the workspace manifest — 12 members. The difference is synapse-engine-owned/owned-decode-worker, a nested subcrate that a directory listing structurally cannot see.

So the issue I filed about an enumeration gap was itself produced by an incomplete enumeration. I even ran a negative control on that detector and it passed — because the control proves the not-found branch fires, and says nothing about whether the input set was complete. A detector can be correct on every item it is given and still be wrong about which items exist. That is a distinct failure from the ones this repo has been closing: not a check that cannot report absence, but a check whose domain is short.

The general form, which I would rather state than let sit as a one-off: enumerate from the source the build uses, not from a proxy that resembles it. crates/* looks like the member list and is not it. Cargo does not read the directory; it reads members. Any guard keyed on the proxy inherits the proxy's blind spots — and would have kept passing while a nested crate went undocumented indefinitely.

Deriving the guard from the manifest is therefore not a tidier implementation of what I proposed. It is the correct one, and mine would have shipped a guard that could not see the very crate it was missing.

On the count

Three documents, three axes, three guards — and worth noting the third was found by the act the first two argued for, which is the loop working rather than a coincidence. The remaining caveat from #5 is unchanged: each guard covers the axis it enumerates, and none covers an axis nobody has thought of. That is what the diff-shaped rule was for, and it stays unbuilt by choice rather than oversight.