Executive summary
The system holds a strong overall standing of 72%, indicating a healthy asset with solid engineering foundations. However, this confidence masks a critical vulnerability in operational maturity that requires immediate attention to protect business continuity. While the code is clean and the architecture sound, the lack of institutional knowledge creates a fragile dependency on specific individuals rather than robust processes.
The value at stake is relatively contained, with a small footprint of roughly 20,000 lines of production code. Rebuilding this system would cost approximately €43,000 and take about three months for a single engineer, suggesting that the primary risk is not financial loss from failure, but rather the high cost of onboarding and the potential for knowledge loss if key personnel depart. The code itself is highly efficient, with no boilerplate or straight-line logic, reflecting a mature development discipline in its construction.
The most significant risk lies in Maturity, which scores only 64%. This lens measures whether a new team can effectively pick up and operate the system. Currently, the documentation is incomplete, omitting key server and client projects, and the architectural decision records are sparse. This gap means that every change carries a higher risk of regression or misunderstanding, slowing down delivery and increasing the likelihood of defects. Without better documentation, the system becomes a black box, eroding trust and increasing operational overhead.
Conversely, the system demonstrates genuine strength in Code Health and Architecture, both scoring above 84%. The code is maintainable, and the structural design minimizes the risk of changes rippling through the system. Performance is also excellent, scoring 100%, ensuring that the system can handle load without degradation. These strengths provide a stable base upon which to address the maturity gaps.
To focus first, leadership should prioritize adding a clear build and run guide to the root documentation. This single action provides the highest leverage by immediately reducing the barrier to entry for new developers and stabilizing the onboarding process. It is a low-cost, high-impact step that begins to close the maturity gap without requiring a major rewrite. Until this is addressed, the system remains partially understood, leaving the business exposed to unnecessary operational risk.
Raise Maturity 64 → 70 (the Healthy floor) ⇒ headline 72 → ~75.
New since the last scan (8+)
- D4 · Duplicated block (20 lines × 2) src/client/conn/http1.rs
- D4 · Duplicated block (17–18 lines × 2) src/client/conn/http1.rs
- D4 · Duplicated block (12 lines × 2) src/proto/h2/mod.rs
- D22 · Duplicate accessor methods for the same underlying data. `take_message` and `message` appear to provide identical functionality (accessing the contained request), likely differing only in ownership semantics (move vs borrow) but named inconsistently with standard Rust conventions (usually `into_inner`/`as_ref` or `take`/`get`).
- D22 · Duplicate accessor methods for the error field. `into_error` and `error` are redundant. In Rust, `into_*` usually implies consuming the value, while `*()` implies borrowing. Having both without clear distinction in signature (e.g., `&Error` vs `Error`) is confusing.
- D22 · Redundant readiness checks. `is_ready()` returns a boolean, while `ready()` returns a Result. In async contexts, `ready()` is typically the blocking/polling operation, while `is_ready()` is a non-blocking peek. However, having both on the same type often leads to misuse where `is_ready()` is checked before calling `ready()`, which is unnecessary if `ready()` is the correct async primitive.
- D22 · Signature collision or ambiguity. The list shows `Connection.without_shutdown()` appearing twice with different return types (`Result` vs `impl Future`). This suggests either an overload that isn't clearly distinguished by parameters, or a documentation error where one is a blocking version and one is async, but they share the same name.
- D22 · Inconsistent parameter naming across Builder methods. Some use `enabled: bool` (e.g., `http09_responses`, `title_case_headers`), while others use `val: bool` (e.g., `half_close`, `writev`, `keep_alive`). This creates visual noise and inconsistency in the API surface.
Rebuild cost & value ~ Modeled — €14,000–€71,000
| Cost to rebuild | €14,000–€71,000 |
|---|---|
| Domain complexity | Standard |
| Quality factor | 1.1× (at 72% quality) |
| Size & shape | Small · effort split not classified (source measured from disk; the effort-tier breakdown is a C#-only syntax walk) |
This codebase represents roughly ~0.3 person-years of build effort (about ~€43,000 to rebuild). Its weakest lens is Maturity at 64% — the part of that asset most exposed by the findings below.
Top priorities
Diagnosis — what's actually going on
Architecture — module dependency matrix
| depends on → | 1 body.length | 2 common.buf | 3 common.time | 4 ext | 5 ffi | 6 rt.bounds.h2_client.sealed_client | 7 rt.io | 8 client.conn.http1.upgrades | 9 client.dispatch | 10 common.date | 11 common.io.compat | 12 common.io.rewind | 13 ffi.task | 14 ffi.body | 15 upgrade | 16 upgrade.sealed | 17 ext.informational | 18 ffi.http_types | 19 proto | 20 proto.h1 | 21 proto.h1.io | 22 proto.h1.encode | 23 proto.h1.conn | 24 proto.h1.dispatch | 25 client.conn.http1 | 26 proto.h2.client | 27 server.conn.http1 | 28 client.conn.http2 | 29 proto.h2.ping | 30 server.conn.http2 | 31 body.incoming | 32 error | 33 proto.h1.decode | 34 body.chan | 35 proto.h1.role | 36 proto.h2.server | 37 proto.h2.upgrade | 38 rt.bounds.h2_common | 39 rt.bounds.h2_client | 40 rt.bounds.h2_server |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 body.length | ||||||||||||||||||||||||||||||||||||||||
| 2 common.buf | ||||||||||||||||||||||||||||||||||||||||
| 3 common.time | ||||||||||||||||||||||||||||||||||||||||
| 4 ext | ||||||||||||||||||||||||||||||||||||||||
| 5 ffi | ||||||||||||||||||||||||||||||||||||||||
| 6 rt.bounds.h2_client.sealed_client | ||||||||||||||||||||||||||||||||||||||||
| 7 rt.io | ||||||||||||||||||||||||||||||||||||||||
| 8 client.conn.http1.upgrades | 1 | |||||||||||||||||||||||||||||||||||||||
| 9 client.dispatch | 2 | |||||||||||||||||||||||||||||||||||||||
| 10 common.date | 1 | |||||||||||||||||||||||||||||||||||||||
| 11 common.io.compat | 1 | |||||||||||||||||||||||||||||||||||||||
| 12 common.io.rewind | 3 | |||||||||||||||||||||||||||||||||||||||
| 13 ffi.task | 1 | |||||||||||||||||||||||||||||||||||||||
| 14 ffi.body | 2 | |||||||||||||||||||||||||||||||||||||||
| 15 upgrade | 5 | 1 | 2 | |||||||||||||||||||||||||||||||||||||
| 16 upgrade.sealed | 1 | |||||||||||||||||||||||||||||||||||||||
| 17 ext.informational | 1 | 1 | ||||||||||||||||||||||||||||||||||||||
| 18 ffi.http_types | 2 | 1 | 2 | 3 | ||||||||||||||||||||||||||||||||||||
| 19 proto | 1 | |||||||||||||||||||||||||||||||||||||||
| 20 proto.h1 | 1 | 1 | 4 | 1 | ||||||||||||||||||||||||||||||||||||
| 21 proto.h1.io | 1 | 1 | ||||||||||||||||||||||||||||||||||||||
| 22 proto.h1.encode | 1 | 1 | 1 | 1 | ||||||||||||||||||||||||||||||||||||
| 23 proto.h1.conn | 2 | 4 | 1 | 2 | 1 | 1 | 1 | 1 | 2 | 1 | ||||||||||||||||||||||||||||||
| 24 proto.h1.dispatch | 1 | 1 | ||||||||||||||||||||||||||||||||||||||
| 25 client.conn.http1 | 1 | 1 | 1 | |||||||||||||||||||||||||||||||||||||
| 26 proto.h2.client | 1 | 1 | 2 | 1 | 2 | |||||||||||||||||||||||||||||||||||
| 27 server.conn.http1 | 2 | 4 | ||||||||||||||||||||||||||||||||||||||
| 28 client.conn.http2 | 1 | 1 | 2 | 1 | ||||||||||||||||||||||||||||||||||||
| 29 proto.h2.ping | 3 | 1 | 1 | 3 | ||||||||||||||||||||||||||||||||||||
| 30 server.conn.http2 | 1 | 1 | 1 | |||||||||||||||||||||||||||||||||||||
| 31 body.incoming | 1 | 1 | 1 | |||||||||||||||||||||||||||||||||||||
| 32 error | 2 | 2 | ||||||||||||||||||||||||||||||||||||||
| 33 proto.h1.decode | 1 | 1 | ||||||||||||||||||||||||||||||||||||||
| 34 body.chan | 2 | |||||||||||||||||||||||||||||||||||||||
| 35 proto.h1.role | 1 | 2 | 1 | 3 | 8 | 2 | 1 | 2 | ||||||||||||||||||||||||||||||||
| 36 proto.h2.server | 1 | 1 | 1 | 1 | 1 | |||||||||||||||||||||||||||||||||||
| 37 proto.h2.upgrade | 3 | 2 | 1 | 2 | ||||||||||||||||||||||||||||||||||||
| 38 rt.bounds.h2_common | 1 | |||||||||||||||||||||||||||||||||||||||
| 39 rt.bounds.h2_client | 1 | 1 | 1 | |||||||||||||||||||||||||||||||||||||
| 40 rt.bounds.h2_server | 1 | 1 | 1 |
8→25 client.conn.http1.upgrades depends on client.conn.http1 cycle✕
- Type pairs
- 1 distinct (type in client.conn.http1.upgrades → type in client.conn.http1) reference.
- Which types
hyper.client.conn.http1.upgrades.UpgradeableConnection→hyper.client.conn.http1.Connection
- Direction
- client.conn.http1.upgrades uses client.conn.http1. Changing client.conn.http1 can break client.conn.http1.upgrades, not the reverse.
- Position
- Above the diagonal — a cycle. Neither module can be changed, tested or deployed independently until one of these dependencies goes.
9→32 client.dispatch depends on error cycle✕
- Type pairs
- 2 distinct (type in client.dispatch → type in error) references.
- Which types
hyper.client.dispatch.TrySendError→hyper.error.Errorhyper.client.dispatch.dispatch$module→hyper.error.Error
- Direction
- client.dispatch uses error. Changing error can break client.dispatch, not the reverse.
- Position
- Above the diagonal — a cycle. Neither module can be changed, tested or deployed independently until one of these dependencies goes.
10→7 common.date depends on rt.io✕
- Type pairs
- 1 distinct (type in common.date → type in rt.io) reference.
- Which types
hyper.common.date.CachedDate→hyper.rt.io.Write
- Direction
- common.date uses rt.io. Changing rt.io can break common.date, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
11→7 common.io.compat depends on rt.io✕
- Type pairs
- 1 distinct (type in common.io.compat → type in rt.io) reference.
- Which types
hyper.common.io.compat.Compat→hyper.rt.io.ReadBuf
- Direction
- common.io.compat uses rt.io. Changing rt.io can break common.io.compat, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
12→7 common.io.rewind depends on rt.io✕
- Type pairs
- 3 distinct (type in common.io.rewind → type in rt.io) references.
- Which types
hyper.common.io.rewind.Rewind→hyper.rt.io.Readhyper.common.io.rewind.Rewind→hyper.rt.io.ReadBufCursorhyper.common.io.rewind.Rewind→hyper.rt.io.Write
- Direction
- common.io.rewind uses rt.io. Changing rt.io can break common.io.rewind, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
13→5 ffi.task depends on ffi✕
- Type pairs
- 1 distinct (type in ffi.task → type in ffi) reference.
- Which types
hyper.ffi.task.hyper_task→hyper.ffi.UserDataPointer
- Direction
- ffi.task uses ffi. Changing ffi can break ffi.task, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
14→13 ffi.body depends on ffi.task✕
- Type pairs
- 2 distinct (type in ffi.body → type in ffi.task) references.
- Which types
hyper.ffi.body.hyper_buf→hyper.ffi.task.AsTaskTypehyper.ffi.body.hyper_buf→hyper.ffi.task.hyper_task_return_type
- Direction
- ffi.body uses ffi.task. Changing ffi.task can break ffi.body, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
15→7 upgrade depends on rt.io✕
- Type pairs
- 5 distinct (type in upgrade → type in rt.io) references.
- Which types
hyper.upgrade.Io→hyper.rt.io.Readhyper.upgrade.Io→hyper.rt.io.Writehyper.upgrade.Upgraded→hyper.rt.io.Readhyper.upgrade.Upgraded→hyper.rt.io.ReadBufCursorhyper.upgrade.Upgraded→hyper.rt.io.Write
- Direction
- upgrade uses rt.io. Changing rt.io can break upgrade, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
15→12 upgrade depends on common.io.rewind✕
- Type pairs
- 1 distinct (type in upgrade → type in common.io.rewind) reference.
- Which types
hyper.upgrade.Upgraded→hyper.common.io.rewind.Rewind
- Direction
- upgrade uses common.io.rewind. Changing common.io.rewind can break upgrade, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
15→34 upgrade depends on body.chan cycle✕
- Type pairs
- 2 distinct (type in upgrade → type in body.chan) references.
- Which types
hyper.upgrade.OnUpgrade→hyper.body.chan.Receiverhyper.upgrade.Pending→hyper.body.chan.Sender
- Direction
- upgrade uses body.chan. Changing body.chan can break upgrade, not the reverse.
- Position
- Above the diagonal — a cycle. Neither module can be changed, tested or deployed independently until one of these dependencies goes.
16→15 upgrade.sealed depends on upgrade✕
- Type pairs
- 1 distinct (type in upgrade.sealed → type in upgrade) reference.
- Which types
hyper.upgrade.sealed.CanUpgrade→hyper.upgrade.OnUpgrade
- Direction
- upgrade.sealed uses upgrade. Changing upgrade can break upgrade.sealed, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
17→15 ext.informational depends on upgrade✕
- Type pairs
- 1 distinct (type in ext.informational → type in upgrade) reference.
- Which types
hyper.ext.informational.Response→hyper.upgrade.OnUpgrade
- Direction
- ext.informational uses upgrade. Changing upgrade can break ext.informational, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
17→16 ext.informational depends on upgrade.sealed✕
- Type pairs
- 1 distinct (type in ext.informational → type in upgrade.sealed) reference.
- Which types
hyper.ext.informational.Response→hyper.upgrade.sealed.CanUpgrade
- Direction
- ext.informational uses upgrade.sealed. Changing upgrade.sealed can break ext.informational, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
18→4 ffi.http_types depends on ext✕
- Type pairs
- 2 distinct (type in ffi.http_types → type in ext) references.
- Which types
hyper.ffi.http_types.hyper_headers→hyper.ext.HeaderCaseMaphyper.ffi.http_types.hyper_headers→hyper.ext.OriginalHeaderOrder
- Direction
- ffi.http_types uses ext. Changing ext can break ffi.http_types, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
18→5 ffi.http_types depends on ffi✕
- Type pairs
- 1 distinct (type in ffi.http_types → type in ffi) reference.
- Which types
hyper.ffi.http_types.OnInformational→hyper.ffi.UserDataPointer
- Direction
- ffi.http_types uses ffi. Changing ffi can break ffi.http_types, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
18→13 ffi.http_types depends on ffi.task✕
- Type pairs
- 2 distinct (type in ffi.http_types → type in ffi.task) references.
- Which types
hyper.ffi.http_types.hyper_response→hyper.ffi.task.AsTaskTypehyper.ffi.http_types.hyper_response→hyper.ffi.task.hyper_task_return_type
- Direction
- ffi.http_types uses ffi.task. Changing ffi.task can break ffi.http_types, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
18→17 ffi.http_types depends on ext.informational✕
- Type pairs
- 3 distinct (type in ffi.http_types → type in ext.informational) references.
- Which types
hyper.ffi.http_types.OnInformational→hyper.ext.informational.OnInformationalCallbackhyper.ffi.http_types.OnInformational→hyper.ext.informational.Responsehyper.ffi.http_types.hyper_response→hyper.ext.informational.Response
- Direction
- ffi.http_types uses ext.informational. Changing ext.informational can break ffi.http_types, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
19→17 proto depends on ext.informational✕
- Type pairs
- 1 distinct (type in proto → type in ext.informational) reference.
- Which types
hyper.proto.MessageHead→hyper.ext.informational.Response
- Direction
- proto uses ext.informational. Changing ext.informational can break proto, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
20→1 proto.h1 depends on body.length✕
- Type pairs
- 1 distinct (type in proto.h1 → type in body.length) reference.
- Which types
hyper.proto.h1.ParsedMessage→hyper.body.length.DecodedLength
- Direction
- proto.h1 uses body.length. Changing body.length can break proto.h1, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
20→17 proto.h1 depends on ext.informational✕
- Type pairs
- 1 distinct (type in proto.h1 → type in ext.informational) reference.
- Which types
hyper.proto.h1.ParseContext→hyper.ext.informational.OnInformational
- Direction
- proto.h1 uses ext.informational. Changing ext.informational can break proto.h1, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
20→19 proto.h1 depends on proto✕
- Type pairs
- 4 distinct (type in proto.h1 → type in proto) references.
- Which types
hyper.proto.h1.Encode→hyper.proto.BodyLengthhyper.proto.h1.Encode→hyper.proto.MessageHeadhyper.proto.h1.Http1Transaction→hyper.proto.MessageHeadhyper.proto.h1.ParsedMessage→hyper.proto.MessageHead
- Direction
- proto.h1 uses proto. Changing proto can break proto.h1, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
20→32 proto.h1 depends on error cycle✕
- Type pairs
- 1 distinct (type in proto.h1 → type in error) reference.
- Which types
hyper.proto.h1.Http1Transaction→hyper.error.Error
- Direction
- proto.h1 uses error. Changing error can break proto.h1, not the reverse.
- Position
- Above the diagonal — a cycle. Neither module can be changed, tested or deployed independently until one of these dependencies goes.
21→2 proto.h1.io depends on common.buf✕
- Type pairs
- 1 distinct (type in proto.h1.io → type in common.buf) reference.
- Which types
hyper.proto.h1.io.WriteBuf→hyper.common.buf.BufList
- Direction
- proto.h1.io uses common.buf. Changing common.buf can break proto.h1.io, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
21→20 proto.h1.io depends on proto.h1✕
- Type pairs
- 1 distinct (type in proto.h1.io → type in proto.h1) reference.
- Which types
hyper.proto.h1.io.Buffered→hyper.proto.h1.ParseContext
- Direction
- proto.h1.io uses proto.h1. Changing proto.h1 can break proto.h1.io, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
22→7 proto.h1.encode depends on rt.io✕
- Type pairs
- 1 distinct (type in proto.h1.encode → type in rt.io) reference.
- Which types
hyper.proto.h1.encode.ChunkSize→hyper.rt.io.Write
- Direction
- proto.h1.encode uses rt.io. Changing rt.io can break proto.h1.encode, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
22→21 proto.h1.encode depends on proto.h1.io✕
- Type pairs
- 1 distinct (type in proto.h1.encode → type in proto.h1.io) reference.
- Which types
hyper.proto.h1.encode.Encoder→hyper.proto.h1.io.WriteBuf
- Direction
- proto.h1.encode uses proto.h1.io. Changing proto.h1.io can break proto.h1.encode, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
22→31 proto.h1.encode depends on body.incoming cycle✕
- Type pairs
- 1 distinct (type in proto.h1.encode → type in body.incoming) reference.
- Which types
hyper.proto.h1.encode.Encoder→hyper.body.incoming.Kind
- Direction
- proto.h1.encode uses body.incoming. Changing body.incoming can break proto.h1.encode, not the reverse.
- Position
- Above the diagonal — a cycle. Neither module can be changed, tested or deployed independently until one of these dependencies goes.
22→32 proto.h1.encode depends on error cycle✕
- Type pairs
- 1 distinct (type in proto.h1.encode → type in error) reference.
- Which types
hyper.proto.h1.encode.NotEof→hyper.error.Error
- Direction
- proto.h1.encode uses error. Changing error can break proto.h1.encode, not the reverse.
- Position
- Above the diagonal — a cycle. Neither module can be changed, tested or deployed independently until one of these dependencies goes.
23→3 proto.h1.conn depends on common.time✕
- Type pairs
- 2 distinct (type in proto.h1.conn → type in common.time) references.
- Which types
hyper.proto.h1.conn.Conn→hyper.common.time.Timehyper.proto.h1.conn.State→hyper.common.time.Time
- Direction
- proto.h1.conn uses common.time. Changing common.time can break proto.h1.conn, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
23→15 proto.h1.conn depends on upgrade✕
- Type pairs
- 4 distinct (type in proto.h1.conn → type in upgrade) references.
- Which types
hyper.proto.h1.conn.Conn→hyper.upgrade.OnUpgradehyper.proto.h1.conn.Conn→hyper.upgrade.Pendinghyper.proto.h1.conn.State→hyper.upgrade.OnUpgradehyper.proto.h1.conn.State→hyper.upgrade.Pending
- Direction
- proto.h1.conn uses upgrade. Changing upgrade can break proto.h1.conn, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
23→17 proto.h1.conn depends on ext.informational✕
- Type pairs
- 1 distinct (type in proto.h1.conn → type in ext.informational) reference.
- Which types
hyper.proto.h1.conn.State→hyper.ext.informational.OnInformational
- Direction
- proto.h1.conn uses ext.informational. Changing ext.informational can break proto.h1.conn, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
23→19 proto.h1.conn depends on proto✕
- Type pairs
- 2 distinct (type in proto.h1.conn → type in proto) references.
- Which types
hyper.proto.h1.conn.Conn→hyper.proto.BodyLengthhyper.proto.h1.conn.Conn→hyper.proto.MessageHead
- Direction
- proto.h1.conn uses proto. Changing proto can break proto.h1.conn, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
23→21 proto.h1.conn depends on proto.h1.io✕
- Type pairs
- 1 distinct (type in proto.h1.conn → type in proto.h1.io) reference.
- Which types
hyper.proto.h1.conn.Conn→hyper.proto.h1.io.Buffered
- Direction
- proto.h1.conn uses proto.h1.io. Changing proto.h1.io can break proto.h1.conn, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
23→22 proto.h1.conn depends on proto.h1.encode✕
- Type pairs
- 1 distinct (type in proto.h1.conn → type in proto.h1.encode) reference.
- Which types
hyper.proto.h1.conn.Conn→hyper.proto.h1.encode.Encoder
- Direction
- proto.h1.conn uses proto.h1.encode. Changing proto.h1.encode can break proto.h1.conn, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
23→25 proto.h1.conn depends on client.conn.http1 cycle✕
- Type pairs
- 1 distinct (type in proto.h1.conn → type in client.conn.http1) reference.
- Which types
hyper.proto.h1.conn.Conn→hyper.client.conn.http1.Connection
- Direction
- proto.h1.conn uses client.conn.http1. Changing client.conn.http1 can break proto.h1.conn, not the reverse.
- Position
- Above the diagonal — a cycle. Neither module can be changed, tested or deployed independently until one of these dependencies goes.
23→29 proto.h1.conn depends on proto.h2.ping cycle✕
- Type pairs
- 1 distinct (type in proto.h1.conn → type in proto.h2.ping) reference.
- Which types
hyper.proto.h1.conn.Conn→hyper.proto.h2.ping.Ponger
- Direction
- proto.h1.conn uses proto.h2.ping. Changing proto.h2.ping can break proto.h1.conn, not the reverse.
- Position
- Above the diagonal — a cycle. Neither module can be changed, tested or deployed independently until one of these dependencies goes.
23→32 proto.h1.conn depends on error cycle✕
- Type pairs
- 2 distinct (type in proto.h1.conn → type in error) references.
- Which types
hyper.proto.h1.conn.Conn→hyper.error.Errorhyper.proto.h1.conn.State→hyper.error.Error
- Direction
- proto.h1.conn uses error. Changing error can break proto.h1.conn, not the reverse.
- Position
- Above the diagonal — a cycle. Neither module can be changed, tested or deployed independently until one of these dependencies goes.
23→34 proto.h1.conn depends on body.chan cycle✕
- Type pairs
- 1 distinct (type in proto.h1.conn → type in body.chan) reference.
- Which types
hyper.proto.h1.conn.Conn→hyper.body.chan.State
- Direction
- proto.h1.conn uses body.chan. Changing body.chan can break proto.h1.conn, not the reverse.
- Position
- Above the diagonal — a cycle. Neither module can be changed, tested or deployed independently until one of these dependencies goes.
24→23 proto.h1.dispatch depends on proto.h1.conn✕
- Type pairs
- 1 distinct (type in proto.h1.dispatch → type in proto.h1.conn) reference.
- Which types
hyper.proto.h1.dispatch.Dispatcher→hyper.proto.h1.conn.Conn
- Direction
- proto.h1.dispatch uses proto.h1.conn. Changing proto.h1.conn can break proto.h1.dispatch, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
24→34 proto.h1.dispatch depends on body.chan cycle✕
- Type pairs
- 1 distinct (type in proto.h1.dispatch → type in body.chan) reference.
- Which types
hyper.proto.h1.dispatch.SenderDropGuard→hyper.body.chan.Sender
- Direction
- proto.h1.dispatch uses body.chan. Changing body.chan can break proto.h1.dispatch, not the reverse.
- Position
- Above the diagonal — a cycle. Neither module can be changed, tested or deployed independently until one of these dependencies goes.
25→8 client.conn.http1 depends on client.conn.http1.upgrades✕
- Type pairs
- 1 distinct (type in client.conn.http1 → type in client.conn.http1.upgrades) reference.
- Which types
hyper.client.conn.http1.Connection→hyper.client.conn.http1.upgrades.UpgradeableConnection
- Direction
- client.conn.http1 uses client.conn.http1.upgrades. Changing client.conn.http1.upgrades can break client.conn.http1, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
25→24 client.conn.http1 depends on proto.h1.dispatch✕
- Type pairs
- 1 distinct (type in client.conn.http1 → type in proto.h1.dispatch) reference.
- Which types
hyper.client.conn.http1.Connection→hyper.proto.h1.dispatch.Dispatcher
- Direction
- client.conn.http1 uses proto.h1.dispatch. Changing proto.h1.dispatch can break client.conn.http1, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
25→34 client.conn.http1 depends on body.chan cycle✕
- Type pairs
- 1 distinct (type in client.conn.http1 → type in body.chan) reference.
- Which types
hyper.client.conn.http1.SendRequest→hyper.body.chan.Sender
- Direction
- client.conn.http1 uses body.chan. Changing body.chan can break client.conn.http1, not the reverse.
- Position
- Above the diagonal — a cycle. Neither module can be changed, tested or deployed independently until one of these dependencies goes.
26→3 proto.h2.client depends on common.time✕
- Type pairs
- 1 distinct (type in proto.h2.client → type in common.time) reference.
- Which types
hyper.proto.h2.client.client$module→hyper.common.time.Time
- Direction
- proto.h2.client uses common.time. Changing common.time can break proto.h2.client, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
26→9 proto.h2.client depends on client.dispatch✕
- Type pairs
- 1 distinct (type in proto.h2.client → type in client.dispatch) reference.
- Which types
hyper.proto.h2.client.FutCtx→hyper.client.dispatch.Callback
- Direction
- proto.h2.client uses client.dispatch. Changing client.dispatch can break proto.h2.client, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
26→25 proto.h2.client depends on client.conn.http1✕
- Type pairs
- 2 distinct (type in proto.h2.client → type in client.conn.http1) references.
- Which types
hyper.proto.h2.client.ClientTask→hyper.client.conn.http1.SendRequesthyper.proto.h2.client.client$module→hyper.client.conn.http1.Builder
- Direction
- proto.h2.client uses client.conn.http1. Changing client.conn.http1 can break proto.h2.client, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
26→29 proto.h2.client depends on proto.h2.ping cycle✕
- Type pairs
- 1 distinct (type in proto.h2.client → type in proto.h2.ping) reference.
- Which types
hyper.proto.h2.client.ClientTask→hyper.proto.h2.ping.Recorder
- Direction
- proto.h2.client uses proto.h2.ping. Changing proto.h2.ping can break proto.h2.client, not the reverse.
- Position
- Above the diagonal — a cycle. Neither module can be changed, tested or deployed independently until one of these dependencies goes.
26→34 proto.h2.client depends on body.chan cycle✕
- Type pairs
- 2 distinct (type in proto.h2.client → type in body.chan) references.
- Which types
hyper.proto.h2.client.ConnTask→hyper.body.chan.Receiverhyper.proto.h2.client.ConnTask→hyper.body.chan.Sender
- Direction
- proto.h2.client uses body.chan. Changing body.chan can break proto.h2.client, not the reverse.
- Position
- Above the diagonal — a cycle. Neither module can be changed, tested or deployed independently until one of these dependencies goes.
27→3 server.conn.http1 depends on common.time✕
- Type pairs
- 2 distinct (type in server.conn.http1 → type in common.time) references.
- Which types
hyper.server.conn.http1.Builder→hyper.common.time.Durhyper.server.conn.http1.Builder→hyper.common.time.Time
- Direction
- server.conn.http1 uses common.time. Changing common.time can break server.conn.http1, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
27→25 server.conn.http1 depends on client.conn.http1✕
- Type pairs
- 4 distinct (type in server.conn.http1 → type in client.conn.http1) references.
- Which types
hyper.server.conn.http1.Builder→hyper.client.conn.http1.Builderhyper.server.conn.http1.Builder→hyper.client.conn.http1.Connectionhyper.server.conn.http1.UpgradeableConnection→hyper.client.conn.http1.Connectionhyper.server.conn.http1.UpgradeableConnection→hyper.client.conn.http1.Parts
- Direction
- server.conn.http1 uses client.conn.http1. Changing client.conn.http1 can break server.conn.http1, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
28→3 client.conn.http2 depends on common.time✕
- Type pairs
- 1 distinct (type in client.conn.http2 → type in common.time) reference.
- Which types
hyper.client.conn.http2.Builder→hyper.common.time.Time
- Direction
- client.conn.http2 uses common.time. Changing common.time can break client.conn.http2, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
28→9 client.conn.http2 depends on client.dispatch✕
- Type pairs
- 1 distinct (type in client.conn.http2 → type in client.dispatch) reference.
- Which types
hyper.client.conn.http2.SendRequest→hyper.client.dispatch.UnboundedSender
- Direction
- client.conn.http2 uses client.dispatch. Changing client.dispatch can break client.conn.http2, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
28→25 client.conn.http2 depends on client.conn.http1✕
- Type pairs
- 2 distinct (type in client.conn.http2 → type in client.conn.http1) references.
- Which types
hyper.client.conn.http2.Builder→hyper.client.conn.http1.Builderhyper.client.conn.http2.SendRequest→hyper.client.conn.http1.SendRequest
- Direction
- client.conn.http2 uses client.conn.http1. Changing client.conn.http1 can break client.conn.http2, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
28→26 client.conn.http2 depends on proto.h2.client✕
- Type pairs
- 1 distinct (type in client.conn.http2 → type in proto.h2.client) reference.
- Which types
hyper.client.conn.http2.Builder→hyper.proto.h2.client.Config
- Direction
- client.conn.http2 uses proto.h2.client. Changing proto.h2.client can break client.conn.http2, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
29→3 proto.h2.ping depends on common.time✕
- Type pairs
- 3 distinct (type in proto.h2.ping → type in common.time) references.
- Which types
hyper.proto.h2.ping.KeepAlive→hyper.common.time.Timehyper.proto.h2.ping.Shared→hyper.common.time.Timehyper.proto.h2.ping.ping$module→hyper.common.time.Time
- Direction
- proto.h2.ping uses common.time. Changing common.time can break proto.h2.ping, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
29→26 proto.h2.ping depends on proto.h2.client✕
- Type pairs
- 1 distinct (type in proto.h2.ping → type in proto.h2.client) reference.
- Which types
hyper.proto.h2.ping.ping$module→hyper.proto.h2.client.Config
- Direction
- proto.h2.ping uses proto.h2.client. Changing proto.h2.client can break proto.h2.ping, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
29→32 proto.h2.ping depends on error cycle✕
- Type pairs
- 1 distinct (type in proto.h2.ping → type in error) reference.
- Which types
hyper.proto.h2.ping.KeepAliveTimedOut→hyper.error.Error
- Direction
- proto.h2.ping uses error. Changing error can break proto.h2.ping, not the reverse.
- Position
- Above the diagonal — a cycle. Neither module can be changed, tested or deployed independently until one of these dependencies goes.
29→34 proto.h2.ping depends on body.chan cycle✕
- Type pairs
- 3 distinct (type in proto.h2.ping → type in body.chan) references.
- Which types
hyper.proto.h2.ping.KeepAlive→hyper.body.chan.Sharedhyper.proto.h2.ping.Ponger→hyper.body.chan.Sharedhyper.proto.h2.ping.Recorder→hyper.body.chan.Shared
- Direction
- proto.h2.ping uses body.chan. Changing body.chan can break proto.h2.ping, not the reverse.
- Position
- Above the diagonal — a cycle. Neither module can be changed, tested or deployed independently until one of these dependencies goes.
30→3 server.conn.http2 depends on common.time✕
- Type pairs
- 1 distinct (type in server.conn.http2 → type in common.time) reference.
- Which types
hyper.server.conn.http2.Builder→hyper.common.time.Time
- Direction
- server.conn.http2 uses common.time. Changing common.time can break server.conn.http2, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
30→25 server.conn.http2 depends on client.conn.http1✕
- Type pairs
- 1 distinct (type in server.conn.http2 → type in client.conn.http1) reference.
- Which types
hyper.server.conn.http2.Builder→hyper.client.conn.http1.Connection
- Direction
- server.conn.http2 uses client.conn.http1. Changing client.conn.http1 can break server.conn.http2, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
30→26 server.conn.http2 depends on proto.h2.client✕
- Type pairs
- 1 distinct (type in server.conn.http2 → type in proto.h2.client) reference.
- Which types
hyper.server.conn.http2.Builder→hyper.proto.h2.client.Config
- Direction
- server.conn.http2 uses proto.h2.client. Changing proto.h2.client can break server.conn.http2, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
31→1 body.incoming depends on body.length✕
- Type pairs
- 1 distinct (type in body.incoming → type in body.length) reference.
- Which types
hyper.body.incoming.Incoming→hyper.body.length.DecodedLength
- Direction
- body.incoming uses body.length. Changing body.length can break body.incoming, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
31→14 body.incoming depends on ffi.body✕
- Type pairs
- 1 distinct (type in body.incoming → type in ffi.body) reference.
- Which types
hyper.body.incoming.Incoming→hyper.ffi.body.UserBody
- Direction
- body.incoming uses ffi.body. Changing ffi.body can break body.incoming, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
31→29 body.incoming depends on proto.h2.ping✕
- Type pairs
- 1 distinct (type in body.incoming → type in proto.h2.ping) reference.
- Which types
hyper.body.incoming.Incoming→hyper.proto.h2.ping.Recorder
- Direction
- body.incoming uses proto.h2.ping. Changing proto.h2.ping can break body.incoming, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
32→13 error depends on ffi.task✕
- Type pairs
- 2 distinct (type in error → type in ffi.task) references.
- Which types
hyper.error.Error→hyper.ffi.task.AsTaskTypehyper.error.Error→hyper.ffi.task.hyper_task_return_type
- Direction
- error uses ffi.task. Changing ffi.task can break error, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
32→31 error depends on body.incoming✕
- Type pairs
- 2 distinct (type in error → type in body.incoming) references.
- Which types
hyper.error.Error→hyper.body.incoming.Kindhyper.error.ErrorImpl→hyper.body.incoming.Kind
- Direction
- error uses body.incoming. Changing body.incoming can break error, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
33→1 proto.h1.decode depends on body.length✕
- Type pairs
- 1 distinct (type in proto.h1.decode → type in body.length) reference.
- Which types
hyper.proto.h1.decode.Decoder→hyper.body.length.DecodedLength
- Direction
- proto.h1.decode uses body.length. Changing body.length can break proto.h1.decode, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
33→31 proto.h1.decode depends on body.incoming✕
- Type pairs
- 1 distinct (type in proto.h1.decode → type in body.incoming) reference.
- Which types
hyper.proto.h1.decode.Decoder→hyper.body.incoming.Kind
- Direction
- proto.h1.decode uses body.incoming. Changing body.incoming can break proto.h1.decode, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
34→32 body.chan depends on error✕
- Type pairs
- 2 distinct (type in body.chan → type in error) references.
- Which types
hyper.body.chan.Sender→hyper.error.Errorhyper.body.chan.State→hyper.error.Error
- Direction
- body.chan uses error. Changing error can break body.chan, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
35→3 proto.h1.role depends on common.time✕
- Type pairs
- 1 distinct (type in proto.h1.role → type in common.time) reference.
- Which types
hyper.proto.h1.role.Server→hyper.common.time.Time
- Direction
- proto.h1.role uses common.time. Changing common.time can break proto.h1.role, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
35→4 proto.h1.role depends on ext✕
- Type pairs
- 2 distinct (type in proto.h1.role → type in ext) references.
- Which types
hyper.proto.h1.role.Server→hyper.ext.HeaderCaseMaphyper.proto.h1.role.role$module→hyper.ext.HeaderCaseMap
- Direction
- proto.h1.role uses ext. Changing ext can break proto.h1.role, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
35→7 proto.h1.role depends on rt.io✕
- Type pairs
- 1 distinct (type in proto.h1.role → type in rt.io) reference.
- Which types
hyper.proto.h1.role.FastWrite→hyper.rt.io.Write
- Direction
- proto.h1.role uses rt.io. Changing rt.io can break proto.h1.role, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
35→19 proto.h1.role depends on proto✕
- Type pairs
- 3 distinct (type in proto.h1.role → type in proto) references.
- Which types
hyper.proto.h1.role.Client→hyper.proto.BodyLengthhyper.proto.h1.role.Client→hyper.proto.MessageHeadhyper.proto.h1.role.Server→hyper.proto.MessageHead
- Direction
- proto.h1.role uses proto. Changing proto can break proto.h1.role, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
35→20 proto.h1.role depends on proto.h1✕
- Type pairs
- 8 distinct (type in proto.h1.role → type in proto.h1) references.
- Which types
hyper.proto.h1.role.Client→hyper.proto.h1.Encodehyper.proto.h1.role.Client→hyper.proto.h1.Http1Transactionhyper.proto.h1.role.Client→hyper.proto.h1.ParseContexthyper.proto.h1.role.Server→hyper.proto.h1.Encodehyper.proto.h1.role.Server→hyper.proto.h1.Http1Transactionhyper.proto.h1.role.Server→hyper.proto.h1.ParseContexthyper.proto.h1.role.role$module→hyper.proto.h1.Encodehyper.proto.h1.role.role$module→hyper.proto.h1.ParseContext
- Direction
- proto.h1.role uses proto.h1. Changing proto.h1 can break proto.h1.role, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
35→22 proto.h1.role depends on proto.h1.encode✕
- Type pairs
- 2 distinct (type in proto.h1.role → type in proto.h1.encode) references.
- Which types
hyper.proto.h1.role.Client→hyper.proto.h1.encode.Encoderhyper.proto.h1.role.role$module→hyper.proto.h1.encode.Encoder
- Direction
- proto.h1.role uses proto.h1.encode. Changing proto.h1.encode can break proto.h1.role, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
35→26 proto.h1.role depends on proto.h2.client✕
- Type pairs
- 1 distinct (type in proto.h1.role → type in proto.h2.client) reference.
- Which types
hyper.proto.h1.role.Server→hyper.proto.h2.client.Config
- Direction
- proto.h1.role uses proto.h2.client. Changing proto.h2.client can break proto.h1.role, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
35→32 proto.h1.role depends on error✕
- Type pairs
- 2 distinct (type in proto.h1.role → type in error) references.
- Which types
hyper.proto.h1.role.Client→hyper.error.Errorhyper.proto.h1.role.Server→hyper.error.Error
- Direction
- proto.h1.role uses error. Changing error can break proto.h1.role, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
36→15 proto.h2.server depends on upgrade✕
- Type pairs
- 1 distinct (type in proto.h2.server → type in upgrade) reference.
- Which types
hyper.proto.h2.server.ConnectParts→hyper.upgrade.Pending
- Direction
- proto.h2.server uses upgrade. Changing upgrade can break proto.h2.server, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
36→25 proto.h2.server depends on client.conn.http1✕
- Type pairs
- 1 distinct (type in proto.h2.server → type in client.conn.http1) reference.
- Which types
hyper.proto.h2.server.Serving→hyper.client.conn.http1.Connection
- Direction
- proto.h2.server uses client.conn.http1. Changing client.conn.http1 can break proto.h2.server, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
36→26 proto.h2.server depends on proto.h2.client✕
- Type pairs
- 1 distinct (type in proto.h2.server → type in proto.h2.client) reference.
- Which types
hyper.proto.h2.server.Config→hyper.proto.h2.client.Config
- Direction
- proto.h2.server uses proto.h2.client. Changing proto.h2.client can break proto.h2.server, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
36→29 proto.h2.server depends on proto.h2.ping✕
- Type pairs
- 1 distinct (type in proto.h2.server → type in proto.h2.ping) reference.
- Which types
hyper.proto.h2.server.ConnectParts→hyper.proto.h2.ping.Recorder
- Direction
- proto.h2.server uses proto.h2.ping. Changing proto.h2.ping can break proto.h2.server, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
36→32 proto.h2.server depends on error✕
- Type pairs
- 1 distinct (type in proto.h2.server → type in error) reference.
- Which types
hyper.proto.h2.server.Serving→hyper.error.Error
- Direction
- proto.h2.server uses error. Changing error can break proto.h2.server, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
37→7 proto.h2.upgrade depends on rt.io✕
- Type pairs
- 3 distinct (type in proto.h2.upgrade → type in rt.io) references.
- Which types
hyper.proto.h2.upgrade.H2Upgraded→hyper.rt.io.Readhyper.proto.h2.upgrade.H2Upgraded→hyper.rt.io.ReadBufCursorhyper.proto.h2.upgrade.H2Upgraded→hyper.rt.io.Write
- Direction
- proto.h2.upgrade uses rt.io. Changing rt.io can break proto.h2.upgrade, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
37→29 proto.h2.upgrade depends on proto.h2.ping✕
- Type pairs
- 2 distinct (type in proto.h2.upgrade → type in proto.h2.ping) references.
- Which types
hyper.proto.h2.upgrade.H2Upgraded→hyper.proto.h2.ping.Recorderhyper.proto.h2.upgrade.upgrade$module→hyper.proto.h2.ping.Recorder
- Direction
- proto.h2.upgrade uses proto.h2.ping. Changing proto.h2.ping can break proto.h2.upgrade, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
37→32 proto.h2.upgrade depends on error✕
- Type pairs
- 1 distinct (type in proto.h2.upgrade → type in error) reference.
- Which types
hyper.proto.h2.upgrade.upgrade$module→hyper.error.Error
- Direction
- proto.h2.upgrade uses error. Changing error can break proto.h2.upgrade, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
37→34 proto.h2.upgrade depends on body.chan✕
- Type pairs
- 2 distinct (type in proto.h2.upgrade → type in body.chan) references.
- Which types
hyper.proto.h2.upgrade.UpgradedSendStreamBridge→hyper.body.chan.Receiverhyper.proto.h2.upgrade.UpgradedSendStreamBridge→hyper.body.chan.Sender
- Direction
- proto.h2.upgrade uses body.chan. Changing body.chan can break proto.h2.upgrade, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
38→37 rt.bounds.h2_common depends on proto.h2.upgrade✕
- Type pairs
- 1 distinct (type in rt.bounds.h2_common → type in proto.h2.upgrade) reference.
- Which types
hyper.rt.bounds.h2_common.Http2UpgradedExec→hyper.proto.h2.upgrade.UpgradedSendStreamTask
- Direction
- rt.bounds.h2_common uses proto.h2.upgrade. Changing proto.h2.upgrade can break rt.bounds.h2_common, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
39→6 rt.bounds.h2_client depends on rt.bounds.h2_client.sealed_client✕
- Type pairs
- 1 distinct (type in rt.bounds.h2_client → type in rt.bounds.h2_client.sealed_client) reference.
- Which types
hyper.rt.bounds.h2_client.Http2ClientConnExec→hyper.rt.bounds.h2_client.sealed_client.Sealed
- Direction
- rt.bounds.h2_client uses rt.bounds.h2_client.sealed_client. Changing rt.bounds.h2_client.sealed_client can break rt.bounds.h2_client, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
39→26 rt.bounds.h2_client depends on proto.h2.client✕
- Type pairs
- 1 distinct (type in rt.bounds.h2_client → type in proto.h2.client) reference.
- Which types
hyper.rt.bounds.h2_client.Http2ClientConnExec→hyper.proto.h2.client.H2ClientFuture
- Direction
- rt.bounds.h2_client uses proto.h2.client. Changing proto.h2.client can break rt.bounds.h2_client, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
39→38 rt.bounds.h2_client depends on rt.bounds.h2_common✕
- Type pairs
- 1 distinct (type in rt.bounds.h2_client → type in rt.bounds.h2_common) reference.
- Which types
hyper.rt.bounds.h2_client.Http2ClientConnExec→hyper.rt.bounds.h2_common.Http2UpgradedExec
- Direction
- rt.bounds.h2_client uses rt.bounds.h2_common. Changing rt.bounds.h2_common can break rt.bounds.h2_client, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
40→6 rt.bounds.h2_server depends on rt.bounds.h2_client.sealed_client✕
- Type pairs
- 1 distinct (type in rt.bounds.h2_server → type in rt.bounds.h2_client.sealed_client) reference.
- Which types
hyper.rt.bounds.h2_server.Http2ServerConnExec→hyper.rt.bounds.h2_client.sealed_client.Sealed
- Direction
- rt.bounds.h2_server uses rt.bounds.h2_client.sealed_client. Changing rt.bounds.h2_client.sealed_client can break rt.bounds.h2_server, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
40→36 rt.bounds.h2_server depends on proto.h2.server✕
- Type pairs
- 1 distinct (type in rt.bounds.h2_server → type in proto.h2.server) reference.
- Which types
hyper.rt.bounds.h2_server.Http2ServerConnExec→hyper.proto.h2.server.H2Stream
- Direction
- rt.bounds.h2_server uses proto.h2.server. Changing proto.h2.server can break rt.bounds.h2_server, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
40→38 rt.bounds.h2_server depends on rt.bounds.h2_common✕
- Type pairs
- 1 distinct (type in rt.bounds.h2_server → type in rt.bounds.h2_common) reference.
- Which types
hyper.rt.bounds.h2_server.Http2ServerConnExec→hyper.rt.bounds.h2_common.Http2UpgradedExec
- Direction
- rt.bounds.h2_server uses rt.bounds.h2_common. Changing rt.bounds.h2_common can break rt.bounds.h2_server, not the reverse.
- Position
- Below the diagonal — points down the layering, which is what you want.
At a glance — Code Health
At a glance — Architecture
At a glance — Maturity
At a glance — Readiness
At a glance — Security
At a glance — Performance
Security & Compliance — OWASP Top-10 mapping
| OWASP category | Findings | Severity |
|---|---|---|
| A03:2021 — Injection | 58 | High / Critical |
Roadmap
Begin by updating the root README with a quick-start guide and correcting omissions of the hyper server and client projects to ensure documentation matches reality. Next, expand the architecture decision records to eight entries and document significant decisions as they occur to raise maturity. Finally, address the single documentation quality finding in the README and resolve the artifact signing gap in the supply chain to secure provenance.
| Do this | Helps | Effort | Dimension |
|---|---|---|---|
| Add a build/run (quick start) section to the root README — the first thing a newcomer needs. | +8.0 pts | Medium | Documentation (README) |
| Grow the ADR log (currently 2) — reach 8 to raise the maturity tier; document significant decisions as they're made. | +8.0 pts | Medium | Architecture documentation |
| Reconcile the README with reality: README omits the hyper server project (tests/h1_server); README omits the hyper client project. | +7.7 pts | Medium | Documentation accuracy |
| Resolve the 1 Documentation finding(s) in Documentation Quality — start with README.md. | +1.5 pts | Low | Documentation Quality |
| Resolve the 1 REDACTED finding(s) in Supply-chain Provenance & Signing. | +1.3 pts | Low | Supply-chain Provenance & Signing |
| Resolve the 1 REDACTED finding(s) in Supply-chain Provenance & Signing. | +1.3 pts | Low | Supply-chain Provenance & Signing |
| Resolve the 1 REDACTED finding(s) in Supply-chain Provenance & Signing. | +1.3 pts | Low | Supply-chain Provenance & Signing |
| Resolve the 2 REDACTED finding(s) in Static Analysis (SAST) — start with REDACTED, REDACTED. | +1.1 pts | Low | Static Analysis (SAST) |
File quality
| File | Score | Band | Worst signal |
|---|---|---|---|
| REDACTED | 2.5 | Slop | Static Analysis (SAST): High: REDACTED |
| REDACTED | 4.4 | Mixed | Static Analysis (SAST): High: REDACTED |
| REDACTED | 5.1 | Mixed | Static Analysis (SAST): High: REDACTED |
| src/proto/h1/role.rs | 6.0 | Mixed | Explicit Debt: TodoComment |
| src/proto/h1/decode.rs | 6.0 | Mixed | Explicit Debt: TodoComment |
| src/proto/h1/conn.rs | 6.0 | Mixed | Explicit Debt: TodoComment |
| src/proto/h1/io.rs | 6.0 | Mixed | Explicit Debt: TodoComment |
| src/client/dispatch.rs | 6.0 | Mixed | Explicit Debt: FixmeComment |
| src/ffi/http_types.rs | 6.2 | Mixed | Change Coupling: Boundary-crossing change coupling: http_types.rs ↔ role.rs |
| src/proto/h1/dispatch.rs | 7.1 | Mixed | Cyclomatic Complexity: Dispatcher::poll_read (cyclomatic 17) |
| src/common/task.rs | 7.3 | Mixed | Explicit Debt: TodoComment |
| src/proto/h2/ping.rs | 7.3 | Mixed | Explicit Debt: XxxComment |
| src/proto/h2/client.rs | 7.4 | Mixed | Cyclomatic Complexity: ClientTask::poll (cyclomatic 19) |
| src/client/conn/http2.rs | 7.4 | Mixed | Code Duplication: Duplicated block (7 lines × 2) |
| src/proto/h2/server.rs | 7.8 | Mixed | Cognitive Complexity: H2Stream::poll2 (cognitive 38) |
| src/proto/h2/mod.rs | 7.8 | Mixed | Cognitive Complexity: PipeToSendStream::poll (cognitive 31) |
| src/client/conn/http1.rs | 7.8 | Mixed | Code Duplication: Duplicated block (20 lines × 2) |
| benches/end_to_end.rs | 8.2 | Near-clean | Explicit Debt: TodoComment |
| benches/connect.rs | 8.2 | Near-clean | Explicit Debt: TodoComment |
| examples/params.rs | 8.2 | Near-clean | Explicit Debt: FixmeComment |
How the grades work
A definite problem that already costs you something and drags the score down: a missing authorisation check, a dependency with a known exploit, a build that does not reproduce. Failure here tends to cause failures elsewhere.
Likely wrong, but not failing yet. It degrades the codebase over a longer horizon and can cause failures elsewhere — not urgent this week, not something to carry for two years either.
Recorded, with no effect on how the codebase functions. Present so the survey is complete, not because it needs doing.
Something this survey could not settle from the outside, and which could be critical or serious. Either a control was required and no positive evidence of it exists in the repository — a backup job that nothing shows was ever restored from proves nothing about restores — or our own analysis could not run over that part of the tree. This is not a clean result. These are excluded from the score rather than awarded a pass, so the number on the cover neither rewards nor penalises them: if you act on this survey without resolving them, you carry that risk yourself. Each one is named under Limitations.
Methodology & how to trust this report
Watchdog is a deep, periodic assessment — run each sprint, monthly, or quarterly, taking the time to go wider and deeper than a quick check and surfacing in one coherent report what you'd otherwise piece together from a dozen separate tools. It scores deterministically: the same commit yields the same score, every run. 28 of 34 evaluated dimensions are computed purely by tools and static analysis (confidence 1.0); 6 documentation/naming judgement(s) are LLM-assisted and labelled advisory. Overall confidence is 0.9 — the weighted average across measured dimensions; it falls as more of the score leans on LLM-assisted judgement and rises when it's fully tool-backed.
What we checked — 34 dimensions across the health lenses
- Can you open the finding? Real findings cite a repo-relative file and line you can open at the cited line — never an absolute scratch path. Here, 144 of 159 do; the remainder are repo-wide signals — a dimension-level measurement, not a single line.
- Is there a tool behind the number? Every score below names the method that produced it — Roslyn, git, a scanner, or (for a handful of documentation/naming dimensions) an LLM labelled sampled · advisory — not a narrative.
- Does re-running give the same result? Run it again on the same commit and the score — and this report, byte for byte — is identical. A report whose numbers move between runs is describing the run, not the code.
Tools & methods
| Method | Backs | Version | Evaluator |
|---|---|---|---|
| Roslyn static analysis | Complexity, cohesion, coupling, dead code, API surface, layering | 5.3.0 | ✓ deterministic |
| Native secret scanner | Hardcoded secrets / credentials | 1.0.0 | ✓ deterministic |
| Watchdog duplication detector (in-process) | Code duplication | 1.0.0 | ✓ deterministic |
| Coverage (coverlet / dotnet-coverage) | Line & branch coverage | 10.0.400 | ✓ deterministic |
| NuGet / dotnet | Outdated, vulnerable & deprecated dependencies | 10.0.400 | ✓ deterministic |
| git / LibGit2Sharp | Churn hotspots, knowledge concentration, history | 2.43.0 · 0.31.0 | ✓ deterministic |
| gitleaks · semgrep · trivy | Secrets in history, SAST, CVEs, IaC & container, PII / GDPR | 1.86.0 · 0.69.3 | ✓ deterministic |
| LLM (sampled · advisory) | Documentation quality, ADR conformance, naming — sampled over a bounded sample; advisory, never a deterministic measurement | Local LLM | ◐ LLM · sampled · advisory |
Run transparency — what happened this run
- D6 Cohesion (LCOM4) — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check's reader does not cover the language this repository's product is written in, so it had nothing of the product to read. That is a gap in this analyzer's language reach — not a finding about this repository.
- D8 Code Coverage — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. Coverage NOT MEASURED: test source is present (.rs) but the built-in coverage collector has no runner for this repository's ecosystem — so this suite was never executed by it. Not scored — this is a gap in the analyzer's language coverage, not a defect in the repo. To have real coverage read, produce a coverage report in a standard format (lcov — `cargo install cargo-llvm-cov`, then `cargo llvm-cov --lcov --output-path lcov.info`) and commit it — a hosted scan measures a clone of the repository, so a report that exists only in a working tree, a CI runner's or your own, never reaches it; the artefact is commonly gitignored, so `git add -f` that one file (or un-ignore its path) and commit it alongside the code it measures. You can widen what we reach: optional: produce a coverage report in a standard format (lcov — `cargo install cargo-llvm-cov`, then `cargo llvm-cov --lcov --output-path lcov.info`) and commit it — a hosted scan measures a clone of the repository, so a report that exists only in a working tree, a CI runner's or your own, never reaches it; the artefact is commonly gitignored, so `git add -f` that one file (or un-ignore its path) and commit it alongside the code it measures — then the real number is read on the next scan.
- D11 Test Reliability — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. Test source is present (.rs) and this repository declares a Cargo test suite (repository root, 26 test files), but it was not re-run: no test result was produced. Not scored — this is a gap in the analyzer's language coverage, not a finding about this repository.
- D12 Dependency Hygiene — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. Not scored — 17 direct Cargo declaration(s) were read, but the outdated signal needs crates.io, and no committed Cargo.lock resolves them to versions, so this dimension's own question is only partly answered. NOT a finding that these dependencies are current or healthy.
- D30 Dependency Vulnerabilities — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. Osv: the scanner produced no output at all, so no dependency was actually scanned. 'osv-scanner' exited 128 and produced no findings, and that exit code has no documented repo-side meaning — so this run measured nothing, and nothing here is a statement about the repository.
- D43 Malicious Dependencies — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. Osv: the scanner produced no output at all, so no dependency was actually scanned. 'osv-scanner' exited 128 and produced no findings, and that exit code has no documented repo-side meaning — so this run measured nothing, and nothing here is a statement about the repository.
- AX1 Captive dependencies — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- AX2 Stateful singletons — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- AX6 Interface segregation — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is computed over the public interfaces this run's compilations declare, and none was loaded, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- AXB1 Runtime evidence locked — no reproducible boot — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. The Runtime Evidence tier boots an app only via docker-compose, an Aspire AppHost, or a Dockerfile. None was found, so no live runtime a11y/egress/header evidence was collected. You can widen what we reach: add a docker-compose.yml (or an Aspire AppHost) that brings the app up with its dependencies. Watchdog then boots it in an isolated sandbox and gathers real runtime evidence — you change nothing in your pipeline (no CI step, no SDK).
- C1 Data Protection — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. These personal data controls are read from declarative annotations, request middleware, entity/column names and guard methods in a C# source model, and none was loaded on this run, so there was nothing to gather. That is a gap in this analyzer's language reach — not a finding that the repository lacks personal data controls.
- C2 Access Controls — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. These authorization controls are read from declarative annotations, request middleware, entity/column names and guard methods in a C# source model, and none was loaded on this run, so there was nothing to gather. That is a gap in this analyzer's language reach — not a finding that the repository lacks authorization controls.
- C3 Audit Trail — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. These audit controls are read from declarative annotations, request middleware, entity/column names and guard methods in a C# source model, and none was loaded on this run, so there was nothing to gather. That is a gap in this analyzer's language reach — not a finding that the repository lacks audit controls.
- C4 Data Retention — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. These retention controls are read from declarative annotations, request middleware, entity/column names and guard methods in a C# source model, and none was loaded on this run, so there was nothing to gather. That is a gap in this analyzer's language reach — not a finding that the repository lacks retention controls.
- C5 Data-Subject Rights — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. These data-subject rights controls are read from declarative annotations, request middleware, entity/column names and guard methods in a C# source model, and none was loaded on this run, so there was nothing to gather. That is a gap in this analyzer's language reach — not a finding that the repository lacks data-subject rights controls.
- ED5 Idempotency — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check finds retry-prone mutations by walking the repository's declared types, and NONE was loaded on this run, so it had nothing to look at. That is a limit of the analyzer's reach — it reads .NET projects — not a finding that this repository has no command handlers or message consumers.
- GD1 Unfinished & placeholder code — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- IC1 Incompleteness & stubs — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- P10 Library API & versioning — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check reads NuGet packaging and C# public API only, and no .NET project was loaded for this repository, so it had nothing of this repository's product to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- P5 DR & Backup — not measured this run — This is a true statement about the repository that carries nothing for its owner to act on, so it is reported here rather than as a defect in their code. No backup/snapshot/replication config, RTO/RPO or restore-procedure documentation was found — and no production persistence was detected either (no data-access packages, no data-store services, no database resources), so there is nothing in this repository whose loss a DR control would recover. If this system's data lives in a platform or ops repo we can't see, that's where the DR evidence belongs.
- PF1 Benchmark discipline — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- PF2 Allocation hygiene — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- S1 Web-Security Posture — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. These web-security controls are read from declarative annotations, request middleware, entity/column names and guard methods in a C# source model, and none was loaded on this run, so there was nothing to gather. That is a gap in this analyzer's language reach — not a finding that the repository lacks web-security controls.
- X1 Async correctness — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X10 Duplicated predicate — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X12 Unreachable branch — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X13 Undrained process stream — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X14 Bypassable address classification — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X15 Unvalidated length from an untrusted reader — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X16 Unfloored truncation loop — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X17 Uncapped recursion over a caller-supplied document — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X18 Disposal-pattern correctness — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X19 Unrestored process-global state — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X2 Cancellation propagation — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X20 Mistyped argument guard — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X21 Side-effecting pattern guard — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X22 Contradicted release guard — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X23 Unguarded diagnostic materialisation — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X24 Document value interpolated into markup unescaped — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X25 Inert configuration knob — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X26 Unsynchronised callback handoff — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X27 Collection changed while being enumerated — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X28 Index access outside its own emptiness guard — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X29 Per-element action decided by a fixed element — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X3 Exception handling — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X30 Support guard that admits what it rejects — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X32 Type resolved by simple name across every loaded assembly — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X4 Structured logging — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X5 Nullable reference types — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X6 Hand-rolled structured-format parsing — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
- X7 Silent fallback defaults — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. This check is implemented over the C# syntax tree, and no C# was loaded on this run, so it had nothing to read. That is a gap in this analyzer's language reach — not a finding that the repository is free of what this check looks for.
Limitations & what we did not check
Watchdog assesses the repository exactly as committed, and only the repository. By design it does not reach outside the source tree: the live cloud account, the running CI/CD pipeline, the host's branch-protection and approval rules, the production configuration, or a restore actually exercised against a backup are all out of scope. That boundary is a feature, not a gap — a repo-relative, deterministic scan re-runs identically on any commit and every finding opens at a real file and line, where a live audit can neither be reproduced nor traced. The visible consequence is that controls which leave no in-repo evidence are reported as "not evidenced" and excluded from the score rather than awarded a number a static scan cannot justify.
Per-dimension blind spots
- D1 Cyclomatic Complexity: Cyclomatic complexity counts branches statically — it cannot tell an essential decision tree from accidental tangle, nor see complexity that lives in data or configuration (large switch-case token tables, DSL lexers/parsers, data-as-code rule tables) rather than control flow: a tokenizer's many single-character cases read as high complexity though each branch is trivial.
- D2 Cognitive Complexity: Cognitive-complexity heuristics approximate how hard code is to follow; genuine domain difficulty and well-named intent that eases reading are not captured.
- D3 God Classes: "God class" is sized by members and responsibilities visible in the type — a deliberately broad facade over a coherent subsystem can read the same as an accidental grab-bag. For front-end JS the file-length check is cohesion-aware (a single-responsibility module — one class/IIFE — earns a 3× threshold), but cohesion is approximated from top-level declarations, not true dependency structure.
- D4 Code Duplication: Duplication is token-similarity — an in-process token-stream comparison over sliding windows, with type-aware normalization — so it finds copy-paste, not semantic duplication expressed differently. Committed machine-written code (scaffolded migrations, designer/codegen output, protobuf/OpenAPI stubs, model snapshots) is EXCLUDED — its repetition is the tool's, not the team's — so the score reflects hand-written duplication only.
- D7 Architectural Integrity: Layering is checked against detected/declared rules — an architecture whose boundaries live in convention or in code review, not in a rule a scanner can read, is not enforced here.
- D9 Test Distribution: The test-pyramid shape is inferred from project/folder naming and references, with a single test host bucketed per-file by its path tier and content signals — a suite that names tiers unconventionally and gives no per-file signal can still be mis-bucketed.
- D13 Secret Scanning: Secret detection is signature- and entropy-based on the current tree — a secret that does not match a known pattern, or one already rotated, will not be flagged (a clean scan is "nothing matched", not "no secrets exist").
- D15 Churn × Complexity Hotspots: Churn hotspots come from git history — a freshly imported or squashed repository has no churn signal, and recent rewrites can mask a historically risky file.
- D16 Bus Factor: Bus-factor is a time-decayed model of commit attribution (who has recently, repeatedly worked a file), not comprehension — pairing, review and reading-without-committing spread knowledge it can't see; bot commits and shared accounts still distort it.
- D17 Explicit Debt: Acknowledged-debt signals (TODO/FIXME, suppressions, dead code) are textual — undocumented debt that nobody marked, and debt that lives in design rather than annotations, is invisible. Committed machine-written code (scaffolded migrations, designer/codegen output, generated stubs) is excluded — it is never the team's dead code to delete.
- D19 Documentation Quality: Documentation quality is judged by an LLM over a bounded sample of docs — it reads what is written, not whether the docs match the running system, and it is advisory, not a measurement. Its critique rows are drawn from a closed category vocabulary and each row means the same thing in every run, so two scans can be compared row by row; the SET that fires is still a sample, and does not repeat exactly. Measured on one frozen input, six scans at one engine SHA: 2-5 critique rows per scan, 8 distinct rows across the six, 3 of those 8 seen in only one scan. So a D19 row is evidence about the documentation, but a COUNT of D19 rows is not a quantity — never read a change in it as an improvement or a regression.
- D20 ADR Quality: ADR quality is an LLM read of the decision records present — it cannot know about decisions made and never recorded, and its verdict is sampled and advisory.
- D21 Naming Consistency: Naming quality is an LLM judgement over a bounded sample — it assesses clarity/consistency of the names it sees, not domain-correctness, and is advisory.
- D22 Internal API Consistency: API-surface coherence is an LLM judgement over a sample of the public surface — consistency of intent across the whole API is approximated, not exhaustively verified.
- D26 Project Cohesion: Project focus is sized from members/namespaces per project — a project that is broad by deliberate design reads the same as one that has sprawled.
- D28 Secrets (history): Secret-history scanning sweeps the git log for known patterns — a secret that predates the available history, or never matched a signature, is not found (clean means "nothing matched in the history we can see").
- D29 Static Analysis (SAST): SAST findings are pattern-based (semgrep) — it finds classes of bug it has rules for; logic flaws, auth/authorization gaps and issues needing runtime context are out of reach (and clean means "no rule matched").
- D34 Knowledge Freshness: Freshness is decayed commit RECENCY, not comprehension — code read often but rarely committed reads as orphaned, and stable code that genuinely needs no changes is penalised the same as forgotten code; bot/squash commits distort it like the bus factor.
- D35 Change Coupling: Change coupling is co-change in COMMITS — files split across separate commits, or coupled only through a shared config/build step, read as uncoupled, and a sweeping commit (rename/format) is excluded so it doesn't couple everything. It shows that files change together, not WHY: a high coupling can be a healthy cohesive pair as readily as a hidden leak.
- D44 Platform End-of-Life: The support table is FROZEN, so it goes out of date by losing RECALL: a release that ended support after the table was written is missed until the table is refreshed, and this dimension reading 10 is not evidence that a platform is current. Only platforms the repository DECLARES in a place this pass reads are seen — a runtime named only in a Dockerfile (D31's subject), in a CI workflow (D29's), or in a file this pass does not parse (go.mod, a Gemfile ruby directive) is invisible here, which is why a repository declaring none of them abstains rather than scoring. Only frameworks with a PUBLISHED support policy are tracked: React, Flask and Express publish none, so their age cannot be judged and their absence from a report is not a statement that they are supported.
- AX10 Code composition: Role is inferred from namespace/folder convention, not semantics — a domain concept living in a folder named "Services" reads as application, and the split is lines-of-code, not business value. The business-logic-share score is a SOFT, FLOORED signal: it contributes to the Architecture lens but is floored at the Critical gate, so an infrastructure-heavy design (a gateway, an ETL, a driver) is legitimately low without being nuked to zero.
- AX9 CQS / query purity: Handlers are found by interface/name convention — a query handler using neither is not seen. Mutation is a resolved write/publish invocation (SaveChanges/repository/bus), so a write hidden behind a hand-rolled wrapper, reflection, or a string-keyed service locator resolves to a non-persistence type and isn't flagged; it detects that a query writes state, not whether the write is a legitimate read-side cache update. Clean means "no resolved write/publish in a query body", not a proof of CQS purity.
- M4 Documentation accuracy: Onboarding quality is an LLM read of the docs/setup present — it cannot run the onboarding or measure how long a real new joiner takes; the verdict is sampled and advisory.
- P6 Release Hygiene: Rollback/observability controls are inferred from repo artefacts (pipelines, dashboards-as-code) — controls configured in external tooling, with no in-repo trace, cannot be credited.
The LLM boundary
Dimensions
D1 · Cyclomatic Complexity
7 function(s) exceeded the cyclomatic complexity threshold of 15; the worst was Server::encode_headers at 50. A further 1 function(s) were over the threshold but excluded as flat dispatchers (a long switch/match over independent cases: many branches, almost no nesting), the largest being Error::description at 32 — they are counted neither in the figure above nor in this dimension's score. 1 file carries no cyclomatic complexity row at all for this reason — every one of its over-threshold functions was excluded, so the exclusion is disclosed nowhere in the file itself: src/error.rs (Error::description at 32). They are named here because the per-file figures other dimensions report are taken BEFORE this exclusion, so such a file can show a high maximum complexity elsewhere in this report and nothing here, with nothing to reconcile the two.
What to do
- Resolve the 2 Server finding(s) in Cyclomatic Complexity — start with role.rs (2). — One of this dimension's main actionable groups (2 warning-level).
- Resolve the 2 Client finding(s) in Cyclomatic Complexity — start with role.rs (2). — One of this dimension's main actionable groups (2 warning-level).
- Resolve the 2 Dispatcher finding(s) in Cyclomatic Complexity — start with dispatch.rs (2). — One of this dimension's main actionable groups (2 warning-level).
- Enforce Cyclomatic Complexity in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
D2 · Cognitive Complexity
18 function(s) exceeded the cognitive complexity threshold of 15; the worst was Server::encode_headers at 122.
What to do
- Resolve the 3 Server finding(s) in Cognitive Complexity — start with role.rs (3). — One of this dimension's main actionable groups (3 warning-level).
- Resolve the 3 Dispatcher finding(s) in Cognitive Complexity — start with dispatch.rs (3). — One of this dimension's main actionable groups (3 warning-level).
- Resolve the 3 Conn finding(s) in Cognitive Complexity — start with conn.rs (3). — One of this dimension's main actionable groups (3 warning-level).
- Enforce Cognitive Complexity in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
D3 · God Classes
10 over-large unit(s) detected — types, modules or files that carry too much.
What to do
- Resolve the 3 MethodTooLong finding(s) in God Classes — start with role.rs (3). — One of this dimension's main actionable groups (3 warning-level).
- Resolve the 3 FileTooLong finding(s) in God Classes — start with role.rs, conn.rs, client.rs. — One of this dimension's main actionable groups (3 warning-level).
- Resolve the 2 TooManyMethods finding(s) in God Classes — start with conn.rs, error.rs. — One of this dimension's main actionable groups (2 warning-level).
- Enforce God Classes in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
D4 · Code Duplication
14 duplicated block group(s) detected.
What to do
- Resolve the 3 Duplicated block (5 lines × 2) finding(s) in Code Duplication — start with role.rs (2), upgrade.rs. — One of this dimension's main actionable groups (3 warning-level).
- Resolve the 2 Duplicated block (12 lines × 2) finding(s) in Code Duplication — start with decode.rs, mod.rs. — One of this dimension's main actionable groups (2 warning-level).
- Resolve the 2 Duplicated block (11 lines × 2) finding(s) in Code Duplication — start with io.rs, role.rs. — One of this dimension's main actionable groups (2 warning-level).
- Enforce Code Duplication in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Verified — provenance only; does not change the score.
D7 · Architectural Integrity
No mechanizable ADR was identified, so enforcement is not measured. Dependency cycles not checked (no project-reference graph; where this repository's language has an import-cycle lens, cycles are reported there).
What to do
- Enforce Architectural Integrity in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
D9 · Test Distribution
257 test methods: 125 unit, 132 integration, 0 BDD, 0 e2e. The Rust suite contributes 257 `#[test]` function(s) across 26 file(s) declaring at least one; its unit/integration split is Cargo's own — 7 of those file(s) are integration-test targets under a crate's tests/ directory, and the rest are #[test] functions compiled into the crate they test.
D13 · Secret Scanning
Secret scan ran and found no leaked secrets.
D15 · Churn × Complexity Hotspots
Top hotspots: src/proto/h1/role.rs (5×33=165); src/proto/h1/conn.rs (7×15=105)
What to do
- Resolve the 2 Hotspot finding(s) in Churn × Complexity Hotspots — start with role.rs, conn.rs. — One of this dimension's main actionable groups (2 warning-level).
D16 · Bus Factor
1 source file(s) have their living knowledge concentrated in one author (≥90% of recent, decayed contribution). The largest is src/common/io/compat.rs. Counted over 46 of the 64 production source files in this repository: the rest are under the ~2,400-byte size floor this dimension measures over.
D17 · Explicit Debt
33 deducted task-comment markers across 19879 LoC (0.2/KLoC) → score 9.7. Task comments only: this repository's language is read without a compiler, so D17's suppression, dead-code and commented-out-code arms did not run and this score counts fewer marker kinds than a .NET repository's would.
What to do
- Resolve the 26 TodoComment finding(s) in Explicit Debt — start with role.rs (6), io.rs (4), task.rs (2). — One of this dimension's main actionable groups (26 warning-level).
- Resolve the 4 FixmeComment finding(s) in Explicit Debt — start with params.rs, mock.rs, tests.rs. — One of this dimension's main actionable groups (4 warning-level).
- Resolve the 3 XxxComment finding(s) in Explicit Debt — start with ping.rs (2), conn.rs. — One of this dimension's main actionable groups (3 warning-level).
- Enforce Explicit Debt in CI to reach Verified (currently Documented). — Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
D19 · Documentation Quality
The repository's root README (README.md) is a clear project overview with an excellent 'Getting started' link to hyper.rs/guides/, plus architecture and usage guidance. The capi/README documents the C API without its own install/usage; the docs/README is a development guide rather than the repo, examples/README is comprehensive and well-structured (dependencies, getting started by example, going further), CODE_OF_CONDUCT, CODE_STYLE, COLLABORATORS, GOVERNANCE, MSRV, PULL_REQUESTS, and ROADMAP-1.0; all are complete and well written for a Rust project. The only unreviewed document is the root README's overview (does it say what hyper is or what it does?), which is clipped by the scanner and cannot be flagged as missing. This repository is well documented: the READMEs are focused on their own directories (e.g. roadmap for hyper VISION, tenets for charter), and there are architecture/design documents covering a full outline (roadmap, vision, tenets, improvement proposals). The documentation is clear, complete, and well-structured across all four levels of detail.
D20 · ADR Quality
Evaluated 1 ADR(s) individually; mean quality 9.0/10 (consistently complete and clear). 0 flagged with a specific gap.
D21 · Naming Consistency
0 naming inconsistencies across 0 sampled symbols.
D22 · Internal API Consistency
5 API inconsistencies across 52 exposed types.
What to do
- Resolve the 1 Duplicate accessor methods for the same underlying data. `take_message`… finding(s) in Internal API Consistency. — One of this dimension's main actionable groups (1 warning-level).
- Resolve the 1 Duplicate accessor methods for the error field. `into_error` and `error`… finding(s) in Internal API Consistency. — One of this dimension's main actionable groups (1 warning-level).
- Resolve the 1 Redundant readiness checks. `is_ready()` returns a boolean, while… finding(s) in Internal API Consistency. — One of this dimension's main actionable groups (1 warning-level).
D26 · Project Cohesion
1 of 1 build units (Cargo) flagged as possibly oversized/incoherent.
What to do
- Resolve the 1 Projects may be oversized for their cohesion finding(s) in Project Cohesion. — One of this dimension's main actionable groups (1 recommendation-level).
D28 · Secrets (history)
gitleaks scanned the full history AND the current working tree and found no secrets.
D29 · Static Analysis (SAST)
58 finding(s): 0 critical, 57 high, 1 medium, 0 low. 55 unpinned-GitHub-Actions row(s) are reported here but scored by D36 (supply-chain provenance), which measures that posture as `pinned_actions` — one pinning decision is charged once, not once per lens. semgrep hit a parse error in 1 file(s) — `.github/ISSUE_TEMPLATE/bug_report.yml` — so no absence of findings in them is evidence of anything, and nothing in them was analysed. Fix the syntax error (or exclude the file deliberately) and re-scan to cover them.
What to do
- Resolve the 2 REDACTED finding(s) in Static Analysis (SAST) — start with REDACTED, REDACTED. — One of this dimension's main actionable groups (2 issue-level).
- Resolve the 1 REDACTED finding(s) in Static Analysis (SAST) — start with REDACTED. — One of this dimension's main actionable groups (1 warning-level).
- No action in Static Analysis (SAST) — all 55 REDACTED finding(s) are reported here at file:line but scored by D36 (supply-chain provenance), so none is charged to this dimension. — One of this dimension's main actionable groups (55 issue-level, 0 of them charged here).
D34 · Knowledge Freshness
1 of 46 significant source file(s) are orphaned — their living knowledge has decayed to nothing, so no one currently understands them. The largest is src/trace.rs. Counted over 46 of the 64 production source files in this repository: the rest are under the ~2,400-byte size floor this dimension measures over.
D35 · Change Coupling
Strongest change-coupling: http_types.rs↔role.rs 69%
What to do
- Resolve the 1 Boundary-crossing change coupling finding(s) in Change Coupling — start with http_types.rs. — One of this dimension's main actionable groups (1 issue-level).
D36 · Supply-chain Provenance & Signing
0/4 supply-chain integrity signals present (provenance, signing, SBOM, pinned actions).
What to do
- Resolve the 1 REDACTED finding(s) in Supply-chain Provenance & Signing. — One of this dimension's main actionable groups (1 warning-level).
- Resolve the 1 REDACTED finding(s) in Supply-chain Provenance & Signing. — One of this dimension's main actionable groups (1 recommendation-level).
- Resolve the 1 REDACTED finding(s) in Supply-chain Provenance & Signing. — One of this dimension's main actionable groups (1 recommendation-level).
D37 · Vulnerability-disclosure Policy
A vulnerability-disclosure policy (SECURITY.md) is published with a reporting contact.
D44 · Platform End-of-Life
0 end-of-life runtime(s) and 0 end-of-life framework(s), read from 1 platform declaration(s) and 0 dependency declaration(s). This dimension reads what the repository says about ITSELF — a pinned target framework, a version file, a capped requires-python, a Rust toolchain pin, a framework major a constraint cannot move off. A FLOOR is deliberately never charged: `requires-python = ">=3.8"` states what the package SUPPORTS, not what it runs on, and a well-maintained library declares exactly that while running its own CI on a current release. The end-of-life facts are FROZEN and dated, so this dimension needs no network and answers identically inside a closed scan fence; as the table ages it loses recall and never precision, because a statement about support that ended in the past cannot become false. The OS layer of a container image is D31's question and the toolchain a CI workflow installs is D29's; this row is neither.
Frontend & cross-cutting dimensions
AX10 · Code composition
What to do
- The domain core is a small share of production code, but most of the rest matched no layer vocabulary at all — so this is not yet an anemic-domain finding. The namespace/path convention could not place that code, which makes the composition above a statement about the naming, not about the design. Name the layers (or check that the repository's conventions differ from the ones this check knows) before reading a thin domain into it.
AX3 · Project dependency cycles
AX4 · Dependency direction
AX9 · CQS / query purity
M1 · Documentation (README)
- 51 code files changed in the last 6 months but the README was not touched — it may no longer reflect the system.
What to do
- Add a build/run (quick start) section to the root README — the first thing a newcomer needs.
- Add a 'Testing' section to the root README — how to run the test suite.
- Add an 'Architecture' / 'How it works' section to the root README — the high-level shape.
- Review the README against recent changes; refresh the parts that drifted.
M2 · Architecture documentation
What to do
- Grow the ADR log (currently 2) — reach 8 to raise the maturity tier; document significant decisions as they're made.
M3 · Folder & project structure
M4 · Documentation accuracy
- README omits the hyper server project (tests/h1_server) — reported by the model that read the README against this repository; no term search was run for this one, so nothing here has been checked against the tree. Treat it as a reading to confirm, not as a measured contradiction: verify it against the code before acting on it, and if the footprint it describes does exist, this row is wrong.
- README omits the hyper client project — reported by the model that read the README against this repository; no term search was run for this one, so nothing here has been checked against the tree. Treat it as a reading to confirm, not as a measured contradiction: verify it against the code before acting on it, and if the footprint it describes does exist, this row is wrong.
What to do
- Reconcile the README with reality: README omits the hyper server project (tests/h1_server); README omits the hyper client project.
P1 · CI/CD gates
P3 · Security & performance tooling
What to do
- Enable Dependabot/Renovate or a dependency-review gate.
- Add gitleaks/trufflehog in CI to block PRs that introduce committed secrets.
P6 · Release Hygiene
PF3 · Async & latency hygiene
Reference — by lens
| Lens | Score | Rating | Impact |
|---|---|---|---|
| Code Health | 89% | Strong | Solid. |
| Architecture | 84% | Adequate — gated by D26 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Maturity | 64% | Adequate | Largest drag on the score — prioritise here. |
| Readiness | 84% | Strong | Solid. |
| Security | 73% | Adequate — gated by D36 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Performance | 100% | Exemplary | Strongest area. |
Not evidenced — 5 control(s) we could not find positive evidence for
- C3 Audit Trail — Not assessed: these audit controls are read from a source model (declarative annotations, request middleware, entity/column names, guard methods) that was not loaded for this repository — because the repository is written in a language this check does not yet model, or because its projects failed to load. Absence of an idiom this check recognises is NOT evidence that this repository lacks audit controls: it may implement them entirely in its own ecosystem. This is a gap in the analyzer's language coverage, not a finding about this repository.
- C4 Data Retention — Not assessed: these retention controls are read from a source model (declarative annotations, request middleware, entity/column names, guard methods) that was not loaded for this repository — because the repository is written in a language this check does not yet model, or because its projects failed to load. Absence of an idiom this check recognises is NOT evidence that this repository lacks retention controls: it may implement them entirely in its own ecosystem. This is a gap in the analyzer's language coverage, not a finding about this repository.
- C5 Data-Subject Rights — Not assessed: these data-subject rights controls are read from a source model (declarative annotations, request middleware, entity/column names, guard methods) that was not loaded for this repository — because the repository is written in a language this check does not yet model, or because its projects failed to load. Absence of an idiom this check recognises is NOT evidence that this repository lacks data-subject rights controls: it may implement them entirely in its own ecosystem. This is a gap in the analyzer's language coverage, not a finding about this repository.
- P4 Deployment & Rollback — not evidenced — no deploy/rollback/approval signal in the repo; absence of evidence is not evidence of a manual release
- P5 DR & Backup — not evidenced — repo shows no backup/RTO/RPO controls; absence of evidence is not evidence of a working control
Not included — 80 check(s) not relevant to this codebase
- AC1 Text alternatives — No web markup found — accessibility is not applicable to this repository.
- AC2 Forms & labels — No web markup found — accessibility is not applicable to this repository.
- AC3 Page structure — No web markup found — accessibility is not applicable to this repository.
- AC4 Keyboard semantics — No web markup found — accessibility is not applicable to this repository.
- AC5 ARIA correctness — No web markup found — accessibility is not applicable to this repository.
- AC6 Visual & motion safety — No web markup found — accessibility is not applicable to this repository.
- AC7 A11y enforcement — No web markup found — accessibility is not applicable to this repository.
- AX1 Captive dependencies — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- AX2 Stateful singletons — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- AX5 Architecture & structure — not assessed — architecture style/structure is computed from a project graph (projects, types, module namespaces) that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- AX6 Interface segregation — not assessed — interface segregation is computed over a type surface that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- AX7 Slice cohesion — not applicable — not a vertical-slice architecture
- AX8 Test isolation — no test/production split to check
- AXB1 Runtime evidence locked — no reproducible boot — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
- C1 Data Protection — Not assessed: these personal data controls are read from a source model (declarative annotations, request middleware, entity/column names, guard methods) that was not loaded for this repository — because the repository is written in a language this check does not yet model, or because its projects failed to load. Absence of an idiom this check recognises is NOT evidence that this repository lacks personal data controls: it may implement them entirely in its own ecosystem. This is a gap in the analyzer's language coverage, not a finding about this repository.
- C2 Access Controls — Not assessed: these authorization controls are read from a source model (declarative annotations, request middleware, entity/column names, guard methods) that was not loaded for this repository — because the repository is written in a language this check does not yet model, or because its projects failed to load. Absence of an idiom this check recognises is NOT evidence that this repository lacks authorization controls: it may implement them entirely in its own ecosystem. This is a gap in the analyzer's language coverage, not a finding about this repository.
- D10 Test Quality — ~10830 lines of test source are present (.rs) but no test cases reached the test census for this repository — no test root we could resolve declared them, or the files we read declare no cases in a test framework we recognise — so skipped/assertion-free tests couldn't be counted. Not scored — this is a gap in the analyzer, not a finding about this repository.
- D11 Test Reliability — Test reliability not included — the .rs suite was found but not re-run
- D12 Dependency Hygiene — Not scored — 17 direct Cargo declaration(s) were read, but the outdated signal needs crates.io, and no committed Cargo.lock resolves them to versions, so this dimension's own question is only partly answered. NOT a finding that these dependencies are current or healthy.
- D14 License Compliance — Not scored — this repository's 42 shipped crate(s) were read from its Cargo.lock, but crates.io could not be asked for the licence of 31 of them (HTTP 429 Unknown Error), and a licence verdict over part of a dependency graph is not a licence verdict. Nothing is asserted about this repository's licensing in either direction.
- D18 Solution Shape — D18 scores the shape of a .NET solution; this repository has no .NET solution or project files, so the dimension does not apply.
- D23 Boundary Type-Coupling — No bounded-context organisation was detected either — neither a context-shaped layout nor 2+ sibling source directories each declaring an aggregate root. Declaring this codebase's bounded contexts (≥2) would let cross-boundary type coupling be assessed. Declare them in `.codehealth/config.yaml` at the repository root (create it if absent), mapping each context name to the module-path or namespace prefixes that belong to it — e.g. `architecture:` → `contexts:` → `Billing: ["src/billing", "Acme.Billing"]`, `Catalog: ["src/catalog", "Acme.Catalog"]`.
- D24 Comment Value — No inline comments to assess — comment value is not applicable here.
- D25 ADR Conformance — none of 1 ADRs are conformance-checkable — unverifiable.
- D27 Navigability — symbol resolution incomplete — too few calls resolved to assess navigability
- D30 Dependency Vulnerabilities — Scanner failed to run — not a clean result
- D31 IaC & Container Security — No Infrastructure-as-Code or container manifests found (Dockerfile, Docker Compose, Terraform, Kubernetes/Helm, CloudFormation, ARM, Bicep, Ansible); nothing to scan.
- D32 Data Compliance (PII/GDPR) — No personal data was found crossing a boundary the PII/GDPR ruleset checks — nothing written to a log or console sink, placed in a URL or query string, or persisted to browser storage. That is a clean result for the LEAK surface only: this ruleset detects personal data escaping, it does not inventory the personal data a repository holds, so it is not evidence that this repository has no personal-data surface. The personal-data map (Appendix C) and the C1-C5 compliance cards are what speak to that.
- D39 IL Efficiency — D39 measures the IL emitted by a .NET build; this repository has no .NET solution or project files, so the dimension does not apply.
- D40 Network Egress Confinement — No Kubernetes/orchestration workloads found in the repository manifests; network egress policy is a cluster-native control that may live at the platform/firewall layer, so there is nothing to assess here.
- D41 Kernel & Syscall Confinement — No Kubernetes/orchestration workloads found in the repository manifests; seccomp/AppArmor/SELinux confinement is a workload-level control, so there is nothing to assess here.
- D42 Runtime Threat Enforcement — No Kubernetes/orchestration workloads found in the repository manifests; runtime threat-detection and admission-control policy are cluster-level controls, so there is nothing to assess here.
- D43 Malicious Dependencies — Scanner failed to run — not a clean result
- D5 Coupling — Not applicable — this Cargo build ships 1 production module(s), so there is no coupling BETWEEN modules to measure. (Its test and non-production modules are not part of the shipped graph.)
- D6 Cohesion (LCOM4) — D6 reads a CS/VB/GO/SCALA/SWIFT/DART/JAVA/PY/KT/TS/TSX/MTS/CTS/JS/JSX/MJS/CJS/PHP class graph only — this repository's production source is .c, .rs, which was left unread. Not scored: this is a gap in the analyzer, not a verdict about this repository.
- D8 Code Coverage — Coverage not included — suite not readable by the collector
- DM1 Domain Modelling — not scored — this repository shows only 1 of the 3 signals this lens looks for (23 value object(s))
- ED2 Event/command shape — not scored — deciding whether a command has more than one competing handler requires resolving the call graph, and a call made through an inferred or generic receiver has no resolvable owner in the source. Reported as guidance rather than measured
- ED5 Idempotency — This check finds retry-prone mutations (command handlers and message/event consumers) by walking the repository's declared types, and none was loaded here, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- ES1 Event Sourcing — not scored — this repository shows none of the 3 signals this lens looks for
- GD1 Unfinished & placeholder code — no source files were read — this check reads C# syntax, and none was loaded for this repository. That is a limit of the analyzer, not a finding about your code.
- IC1 Incompleteness & stubs — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- P10 Library API & versioning — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- P12 CI test-gate honesty — Reported, not scored — and nothing was matched here. The coverage check applies to any stack, and the automatic-re-run check to any GitHub-Actions workflow, but the checks for excluded tests, skipped tests and sleep-based synchronisation currently recognise only some ecosystems' test-runner idioms, so on a repository built with another stack the zeros below mean 'not checked', not 'clean'.
- P2 Observability — This repository's Rust source (1 module(s), 64 file(s) read) declares no entry point and bootstraps no server, and nothing here deploys a service — it is a library, run inside whatever hosts it, so production observability (structured logging, tracing/metrics, health checks) is N/A. If it grows a binary or a service, the dimension reactivates.
- P7 Outbound HTTP resilience — not applicable — no HTTP server, API framework or worker entry point was found in the Rust source, so there is no service whose uptime a failing dependency could take down
- P8 Schema migrations — no ORM, schema-migration tool or schema auto-create was found in this repository's dependency manifests or source, so there is no database schema for this check to judge
- P9 Domain vs controller coverage — no coverage report found on disk — produce a coverage report in a standard format (lcov — `cargo install cargo-llvm-cov`, then `cargo llvm-cov --lcov --output-path lcov.info`) and commit it — a hosted scan measures a clone of the repository, so a report that exists only in a working tree, a CI runner's or your own, never reaches it; the artefact is commonly gitignored, so `git add -f` that one file (or un-ignore its path) and commit it alongside the code it measures, or wire coverage collection into CI, to enable this cross-layer check
- PF1 Benchmark discipline — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- PF2 Allocation hygiene — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- S1 Web-Security Posture — Not assessed: these web-security controls are read from a source model (declarative annotations, request middleware, entity/column names, guard methods) that was not loaded for this repository — because the repository is written in a language this check does not yet model, or because its projects failed to load. Absence of an idiom this check recognises is NOT evidence that this repository lacks web-security controls: it may implement them entirely in its own ecosystem. This is a gap in the analyzer's language coverage, not a finding about this repository.
- X1 Async correctness — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X10 Duplicated predicate — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X12 Unreachable branch — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X13 Undrained process stream — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X14 Bypassable address classification — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X15 Unvalidated length from an untrusted reader — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X16 Unfloored truncation loop — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X17 Uncapped recursion over a caller-supplied document — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X18 Disposal-pattern correctness — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X19 Unrestored process-global state — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X2 Cancellation propagation — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X20 Mistyped argument guard — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X21 Side-effecting pattern guard — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X22 Contradicted release guard — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X23 Unguarded diagnostic materialisation — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X24 Document value interpolated into markup unescaped — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X25 Inert configuration knob — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X26 Unsynchronised callback handoff — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X27 Collection changed while being enumerated — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X28 Index access outside its own emptiness guard — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X29 Per-element action decided by a fixed element — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X3 Exception handling — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X30 Support guard that admits what it rejects — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X32 Type resolved by simple name across every loaded assembly — This check reads C# syntax; no C# was loaded for this repository, so it has nothing to report. That is a limit of the analyzer, not a finding about your code.
- X4 Structured logging — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X5 Nullable reference types — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X6 Hand-rolled structured-format parsing — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X7 Silent fallback defaults — not analysed — these correctness checks read a source model that was not loaded for this repository, because the repository is written in a language this check does not yet model, or because its projects failed to load. This is a gap in the analyzer, not a finding about this repository
- X9 Subsumed condition operand — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
Appendix A — Findings (grouped)
Critical — 58 finding(s)
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- Boundary-crossing change coupling: http_types.rs ↔ role.rs src/ffi/http_types.rs
Serious — 92 finding(s)
- TodoComment benches/end_to_end.rs:7
- TodoComment benches/connect.rs:6
- TodoComment src/upgrade.rs:391
- TodoComment src/common/task.rs:13
- TodoComment src/common/task.rs:39
- TodoComment src/common/future.rs:7
- TodoComment src/common/io/rewind.rs:64
- TodoComment src/ffi/http_types.rs:458
- TodoComment src/proto/h1/role.rs:1631
- TodoComment src/ffi/error.rs:49
- TodoComment src/proto/h1/role.rs:223
- TodoComment src/proto/h1/role.rs:904
- TodoComment src/proto/h1/role.rs:1215
- TodoComment src/proto/h1/role.rs:1244
- TodoComment src/proto/h1/role.rs:1508
- TodoComment src/proto/h1/mod.rs:12
- TodoComment src/proto/h1/io.rs:288
- TodoComment src/proto/h1/io.rs:344
- TodoComment src/proto/h1/io.rs:663
- TodoComment src/proto/h1/decode.rs:24
- TodoComment src/proto/h1/decode.rs:638
- TodoComment src/proto/h1/conn.rs:312
- TodoComment src/proto/h1/conn.rs:320
- TodoComment src/rt/io.rs:544
- TodoComment src/server/conn/http2.rs:97
- FixmeComment examples/params.rs:1
- FixmeComment src/mock.rs:1
- FixmeComment src/client/tests.rs:2
- FixmeComment src/client/dispatch.rs:258
- XxxComment src/proto/h1/conn.rs:349
- XxxComment src/proto/h2/ping.rs:277
- XxxComment src/proto/h2/ping.rs:322
- Server::encode_headers (cognitive 122) src/proto/h1/role.rs:654
- Server::parse (cognitive 53) src/proto/h1/role.rs:146
- Server::encode (cognitive 16) src/proto/h1/role.rs:382
- Dispatcher::poll_write (cognitive 63) src/proto/h1/dispatch.rs:356
- Dispatcher::poll_read (cognitive 51) src/proto/h1/dispatch.rs:225
- Dispatcher::poll_loop (cognitive 17) src/proto/h1/dispatch.rs:166
- Conn::poll_read_head (cognitive 26) src/proto/h1/conn.rs:211
- Conn::poll_read_body (cognitive 22) src/proto/h1/conn.rs:359
- Conn::maybe_notify (cognitive 18) src/proto/h1/conn.rs:517
- MethodTooLong: Server.encode_headers src/proto/h1/role.rs:654
- MethodTooLong: Server.parse src/proto/h1/role.rs:146
- MethodTooLong: Client.parse src/proto/h1/role.rs:1029
- FileTooLong: h1/role.rs src/proto/h1/role.rs
- FileTooLong: h1/conn.rs src/proto/h1/conn.rs
- FileTooLong: h2/client.rs src/proto/h2/client.rs
- Duplicated block (5 lines × 2) src/proto/h1/role.rs:260
- Duplicated block (5 lines × 2) src/proto/h2/upgrade.rs:253
- Duplicated block (5 lines × 2) src/proto/h1/role.rs:169
- Server::encode_headers (cyclomatic 50) src/proto/h1/role.rs:654
- Server::parse (cyclomatic 33) src/proto/h1/role.rs:146
- Client::parse (cyclomatic 26) src/proto/h1/role.rs:1029
- Client::set_length (cyclomatic 17) src/proto/h1/role.rs:1327
- Dispatcher::poll_read (cyclomatic 17) src/proto/h1/dispatch.rs:225
- Dispatcher::poll_write (cyclomatic 17) src/proto/h1/dispatch.rs:356
- Hotspot: src/proto/h1/role.rs src/proto/h1/role.rs:146
- Hotspot: src/proto/h1/conn.rs src/proto/h1/conn.rs:211
- Client::parse (cognitive 57) src/proto/h1/role.rs:1029
- Client::set_length (cognitive 29) src/proto/h1/role.rs:1327
- TooManyMethods: Conn src/proto/h1/conn.rs:38
- TooManyMethods: Error src/error.rs:31
- ClassTooLong: Server src/proto/h1/role.rs:137
- ClassTooLong: Conn src/proto/h1/conn.rs:38
- Duplicated block (12 lines × 2) src/proto/h1/decode.rs:349
- Duplicated block (12 lines × 2) src/proto/h2/mod.rs:164
- Duplicated block (11 lines × 2) src/proto/h1/io.rs:294
- Duplicated block (11 lines × 2) src/proto/h1/role.rs:334
- Duplicated block (7 lines × 2) src/client/conn/http2.rs:334
- Duplicated block (7 lines × 2) src/client/conn/http2.rs:347
- Duplicated block (6 lines × 2) src/client/dispatch.rs:111
- Duplicated block (6 lines × 2) src/client/dispatch.rs:123
- ClientTask::poll (cyclomatic 19) src/proto/h2/client.rs:678
- ClientTask::poll (cognitive 43) src/proto/h2/client.rs:678
- H2Stream::poll2 (cognitive 38) src/proto/h2/server.rs:442
- PipeToSendStream::poll (cognitive 31) src/proto/h2/mod.rs:142
- Decoder::decode (cognitive 29) src/proto/h1/decode.rs:144
- Serving::poll_server (cognitive 24) src/proto/h2/server.rs:248
- Encoder::encode_trailers (cognitive 20) src/proto/h1/encode.rs:163
- Incoming::poll_frame (cognitive 19) src/body/incoming.rs:147
- Duplicate accessor methods for the same underlying data. `take_message` and `message` appear to provide identical functionality (accessing the contained request), likely differing only in ownership semantics (move vs borrow) but named inconsistently with standard Rust conventions (usually `into_inner`/`as_ref` or `take`/`get`).
- Duplicate accessor methods for the error field. `into_error` and `error` are redundant. In Rust, `into_*` usually implies consuming the value, while `*()` implies borrowing. Having both without clear distinction in signature (e.g., `&Error` vs `Error`) is confusing.
- Redundant readiness checks. `is_ready()` returns a boolean, while `ready()` returns a Result. In async contexts, `ready()` is typically the blocking/polling operation, while `is_ready()` is a non-blocking peek. However, having both on the same type often leads to misuse where `is_ready()` is checked before calling `ready()`, which is unnecessary if `ready()` is the correct async primitive.
- Signature collision or ambiguity. The list shows `Connection.without_shutdown()` appearing twice with different return types (`Result` vs `impl Future`). This suggests either an overload that isn't clearly distinguished by parameters, or a documentation error where one is a blocking version and one is async, but they share the same name.
- Inconsistent parameter naming across Builder methods. Some use `enabled: bool` (e.g., `http09_responses`, `title_case_headers`), while others use `val: bool` (e.g., `half_close`, `writev`, `keep_alive`). This creates visual noise and inconsistency in the API surface.
- REDACTED
- REDACTED
- Duplicated block (20 lines × 2) src/client/conn/http1.rs:264
- Duplicated block (17–18 lines × 2) src/client/conn/http1.rs:233
- Duplicated block (10 lines × 2) src/client/conn/http2.rs:377
- README may be stale
Minor — 9 finding(s)
- README/code drift
- README/code drift
- Off-boarding risk: anonymized user #1
- Documentation: no installation or build instructions README.md
- Projects may be oversized for their cohesion
- Orphaned files with no living knowledge
- REDACTED
- REDACTED
- REDACTED
Appendix B — Reproduction & audit trail
| Dimension | Tool | Version | Command | Findings | Raw output |
|---|---|---|---|---|---|
| D28 · Secrets (history) | gitleaks | — | gitleaks detect --no-banner --config /opt/gitleaks-rules/watchdog-gitleaks.toml --report-format json --report-path /tmp/watchdog-gitleaks-db94e1bce21142aa8bf86dafdba59585/history.json --exit-code 0 --source . | 4 | artifacts/raw/gitleaks-history.json |
| D28 · Secrets (history) | gitleaks | — | gitleaks detect --no-git --no-banner --config /opt/gitleaks-rules/watchdog-gitleaks.toml --report-format json --report-path /tmp/watchdog-gitleaks-db94e1bce21142aa8bf86dafdba59585/tree.json --exit-code 0 --source . | 0 | artifacts/raw/gitleaks-tree.json |
| D29 · Static Analysis (SAST) | semgrep | — | semgrep --config /opt/semgrep-rules/security-audit.yml --config /opt/semgrep-rules/owasp-top-ten.yml --config /opt/semgrep-rules/watchdog-sast.yml --json --quiet --timeout 10 --timeout-threshold 3 --metrics off . | 58 | artifacts/raw/semgrep.json |
| D30 · Dependency Vulnerabilities | osv-scanner | — | osv-scanner --format json --recursive . | 0 | — |
| D31 · IaC & Container Security | trivy | — | trivy: not applicable — No Infrastructure-as-Code or container manifests found (Dockerfile, Docker Compose, Terraform, Kubernetes/Helm, CloudFormation, ARM, Bicep, Ansible); nothing to scan. | 0 | — |
| D32 · Data Compliance (PII/GDPR) | semgrep | — | semgrep: not applicable — No personal data was found crossing a boundary the PII/GDPR ruleset checks — nothing written to a log or console sink, placed in a URL or query string, or persisted to browser storage. That is a clean result for the LEAK surface only: this ruleset detects personal data escaping, it does not inventory the personal data a repository holds, so it is not evidence that this repository has no personal-data surface. The personal-data map (Appendix C) and the C1-C5 compliance cards are what speak to that. | 0 | — |
| D40 · Network Egress Confinement | runtime-hardening | — | runtime-hardening: not applicable — No Kubernetes/orchestration workloads found in the repository manifests; network egress policy is a cluster-native control that may live at the platform/firewall layer, so there is nothing to assess here. | 0 | — |
| D41 · Kernel & Syscall Confinement | runtime-hardening | — | runtime-hardening: not applicable — No Kubernetes/orchestration workloads found in the repository manifests; seccomp/AppArmor/SELinux confinement is a workload-level control, so there is nothing to assess here. | 0 | — |
| D42 · Runtime Threat Enforcement | runtime-hardening | — | runtime-hardening: not applicable — No Kubernetes/orchestration workloads found in the repository manifests; runtime threat-detection and admission-control policy are cluster-level controls, so there is nothing to assess here. | 0 | — |
| D43 · Malicious Dependencies | osv-scanner | — | osv-scanner --format json --recursive . | 0 | — |