docs: correct the README snippet, the package-count leftovers and the STmin paragraph

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -19,7 +19,11 @@ body:
         - CanKit.Pro.Actor (threading, scheduling)
         - CanKit.Pro.Addressing (CAN IDs, J1939 fields)
         - CanKit.Pro.Reliability (deadlines, bus state)
-        - A new package (ISO-TP, J1939, CANopen, UDS, ...)
+        - CanKit.Pro.IsoTp (ISO 15765-2 transport)
+        - CanKit.Pro.J1939 / CanKit.Pro.J1939Tp (J1939 and its transport protocols)
+        - CanKit.Pro.Uds (diagnostics)
+        - CanKit.Pro.CANopen
+        - A new package
         - Not sure
     validations:
       required: true

CONTRIBUTING.md

@@ -76,8 +76,8 @@ feat(addressing)!: rename ComposePgn parameters          -> major release
 docs: explain the deadline rearm semantics               -> no release
 ```
 
-Scopes match the packages: `rawcan`, `actor`, `addressing`, `reliability`, plus `docs`, `ci`,
-`build`, `deps`.
+Scopes match the packages: `rawcan`, `actor`, `addressing`, `reliability`, `isotp`, `j1939`,
+`j1939tp`, `uds`, `canopen`, plus `docs`, `ci`, `build`, `deps`.
 
 A breaking change needs both the `!` marker and a footer that says what to do about it:
 
@@ -137,8 +137,7 @@ dotnet build tests/CanKit.Pro.Tests -f net48 -p:CanKitProTestNetFrameworkLeg=tru
 
 These are published libraries, so the public surface is a promise:
 
-- XML documentation on every public type and member. The existing code documents in English with
-  a Chinese translation, inherited from CanKit's own style — English alone is fine for new code.
+- XML documentation on every public type and member. Write them in English.
   Those comments are published verbatim: `eng/build-api-docs.sh` turns them into the
   [API reference](https://dborgards.github.io/CanKit.Pro/api/) on every website build, so what you
   write there is what readers see, and the `FR-…`/`ADR-…` ids you cite become links into the SRS

README.md

@@ -83,11 +83,12 @@ using var service = new CanBusService(bus);
 // One bus, two protocol instances, two disjoint ID ranges — neither starves the other,
 // and a slow consumer cannot block the fast one.
 using var isoTp = service.Subscribe(CanIdFilter.Range(0x700, 0x7FF));
-using var j1939 = service.Subscribe(view => view.IsExtendedFrame);
+using var j1939 = service.Subscribe(e => e.Frame.IsExtendedFrame);
 
 await foreach (var frame in isoTp.Frames.WithCancellation(token))
 {
-    // A read-only CanFrameView: no ownership, no disposal, no aliasing surprises.
+    // A CanFrameEvent: the frame plus its timestamps and echo flag. Its payload is an owned copy,
+    // valid for as long as you hold it; nothing to dispose.
 }
 
 // "Did it actually go out?" — a real echo match where the bus provides one, driver acceptance

SECURITY.md

@@ -22,7 +22,7 @@ credited in the advisory unless you prefer otherwise.
 
 ## Scope
 
-This repository covers the four `CanKit.Pro.*` packages only.
+This repository covers the nine `CanKit.Pro.*` packages only.
 
 Vulnerabilities in **CanKit** itself — adapters, `ICanBus`, frame handling, vendor SDK interop —
 belong to [pkuyo/CanKit](https://github.com/pkuyo/CanKit). CanKit.Pro consumes it as a NuGet

THIRD-PARTY-NOTICES.md

@@ -37,7 +37,8 @@ an ordinary NuGet package. It has no runtime dependencies of its own.
 ### .NET platform packages — MIT
 
 `Microsoft.Bcl.AsyncInterfaces`, `System.Memory` and `System.Threading.Channels` are referenced by
-`CanKit.Pro.RawCan` on `netstandard2.0` only; on `net10.0` those APIs are in the framework and no
+the six packages that use them (`RawCan`, `IsoTp`, `J1939`, `J1939Tp`, `Uds`, `CanOpen`) on
+`netstandard2.0` only; on `net10.0` those APIs are in the framework and no
 package is pulled in.
 
     Copyright (c) .NET Foundation and Contributors
@@ -49,7 +50,7 @@ These never reach a consumer's application: they are `PrivateAssets`/test-projec
 
 | Package | License |
 | --- | --- |
-| [GitVersion.MsBuild](https://github.com/GitTools/GitVersion) | MIT |
+| [GitVersion](https://github.com/GitTools/GitVersion) (`gitversion.tool`, a local dotnet tool) | MIT |
 | [xunit](https://github.com/xunit/xunit), xunit.runner.visualstudio | Apache-2.0 |
 | [Microsoft.NET.Test.Sdk](https://github.com/microsoft/vstest) | MIT |
 | [AwesomeAssertions](https://github.com/AwesomeAssertions/AwesomeAssertions) | Apache-2.0 |

docs/migration-from-legacy.md

@@ -91,7 +91,7 @@ matrix driven by `CANKIT_TEST_ADAPTERS`. CanKit.Pro has no such matrix, so
 
 **The release pipeline.** The legacy repository has nine CI workflows and a PowerShell pipeline
 that detects per-package version bumps from `eng/package-versions.props` — a sensible design for a
-fork tracking upstream's many independently-versioned packages. CanKit.Pro versions all four
+fork tracking upstream's many independently-versioned packages. CanKit.Pro versions all nine
 packages together from the commit history instead, so the whole thing collapses into
 [one CI workflow and one release workflow](release-process.md).
 

src/CanKit.Pro.IsoTp/README.md

@@ -102,13 +102,17 @@ CAN-FD long-payload cases still get the least coverage of the two halves.
 ## Timing accuracy — STmin pacing (NFR-003)
 
 The sender paces Consecutive Frames by the peer's advertised STmin using the L2
-`DeadlineScheduler` (actor-driven, event-based — no busy wait). On general-purpose
-operating systems the effective CF spacing is **STmin + OS scheduling latency**: typically
-within ±1 ms of the configured value on idle Windows/Linux/macOS hosts, with no hard
-real-time guarantee under load. Sub-millisecond STmin values (`0xF1..0xF9`, 100–900 µs)
-are honored as-is but bottom out at the platform timer resolution. Verified end-to-end by
-`tests/CanKit.Pro.Tests/TestCases/IsoTp/IsoTpStminTimingTests.cs` (Virtual-loopback CF-spacing
-measurement with CI-tolerant soft bounds).
+`DeadlineScheduler` (actor-driven, event-based — no busy wait). On general-purpose operating
+systems the effective CF spacing is **STmin + OS scheduling latency**, with no real-time
+guarantee, and nothing in this repository measures how large that latency is on any host.
+Sub-millisecond STmin values (`0xF1..0xF9`, 100–900 µs) are honored as-is but bottom out at the
+platform timer resolution.
+
+What the suite does verify is the logic, not the wall clock:
+`tests/CanKit.Pro.Tests/TestCases/IsoTp/IsoTpStminTimingTests.cs` advances a clock the test drives
+and checks that the sender releases exactly one Consecutive Frame per STmin interval. The
+requirement NFR-003 asks for a documented accuracy (for example ±1 ms); that figure is a target,
+not a measured result.
 
 ## Functional (1:N) addressing — `IsoTpFunctionalClient` (FR-TP-019)