Rayhaan JaufeerallyandClaude Fable 5.1
db8edaae8e
A code-quality pass over policy, configuration and the status API. The twenty TCP gauges were spelled out in the struct, the constructor, the removal, the sampler in the web crate and the status view; one macro names each once with its help text, `PeerTcp::set` fills them from a connection, and the view is a `From`. Every metric and the list that forces them at start come from one declaration, with a test that every declared family is registered. The two revalidators, for next hops and for RPKI, share the task body that scans the table off the sessions' threads and fans the findings out to every session; the RPKI scan judges a route with the same `Checks` the import path uses. Which peer a query names is one rule for the received, rejected and TCP endpoints, so `/api/tcp` takes a name or an address like the others. The config parser says proto3's "zero is unset" in three helpers instead of a dozen shapes, and `parse_peer` is three named parts shorter. The policy's test-only next-hop flag is named for what it does, `accept_own_host_next_hop`; the "listed, or else ours" prefix rule and the mark-then-prefer step each exist once. The status page derives its spanning rows from the table's header, shares one key-value grid and one detail-row rule, and defines its helpers before their use. The web crate no longer re-exports views nothing uses, and the TCP endpoint sits above the test module. Testing: the TCP view's arithmetic (a share of no busy time is zero, not NaN), the peer-naming rule, the RPKI scan finding only what a change can have made invalid, and `/api/tcp` by address, by name and for an unknown peer. The server and web tests, the HTTP, roles, RPKI and import-policy integration tests, the docs build and every lab phase pass. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>