You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 6bfce54
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: README.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,7 +17,7 @@ The suite includes these plugins:
17
17
18
18
To include the optional Streamable HTTP and legacy HTTP+SSE checks, follow the [Core fixture's HTTP setup](plugins/agent-plugins-conformance-core/#optional-http-setup)**before the client loads the plugins**. This starts a bundled local server in a separate terminal; CI can launch the same command. Without the server, HTTP checks remain `not_verified` and the agent continues collecting the other checks.
19
19
20
-
Install and load the plugins through the client's Agent Plugins support, then ask the agent:
20
+
Install and load the plugins from the same [release tag](docs/release-policy.md#release-tags)through the client's Agent Plugins support, then ask the agent:
21
21
22
22
> Run the run-conformance skill from Agent Plugins Conformance and save the JSON report to /tmp/agent-plugins-conformance/report.json.
The suite’s plugins are released together as one suite. Their `plugin.json` versions and the root development package version match the suite release. Install the plugins from the same release tag.
4
+
5
+
Suite versions advance independently of Agent Plugins specification versions. Each suite release targets one exact published specification release; several suite releases can improve coverage of the same specification.
6
+
7
+
## Versioning
8
+
9
+
The suite uses [Semantic Versioning](https://semver.org/). Before `1.0.0`, consumer-facing interfaces are considered unstable. For stable releases:
10
+
11
+
| Change | Increment |
12
+
| --- | --- |
13
+
| Correct a check, improve collection guidance, or fix reporting without breaking a documented consumer interface | Patch |
14
+
| Add checks or other functionality while preserving existing consumer interfaces and prerequisites | Minor |
15
+
| Break the documented saved-report format, remove or redefine check IDs, change required installation or runtime prerequisites incompatibly, or replace the targeted specification version | Major |
16
+
17
+
The collection interface between the guide and reporter, and the protocols between suite components, are internal. They can change together without requiring a major release. The documented saved-report fields and check IDs are interfaces that consumers use for acceptance queries.
18
+
19
+
A corrective patch can change a verdict. New checks can change the result of an acceptance query that selects an entire ID prefix. Therefore, pin an exact suite release for reproducible acceptance testing.
20
+
21
+
## Specification releases
22
+
23
+
A new specification tag does not automatically retarget or release the suite. Adopting it requires validating the suite against that published release and keeping the declared schema targets, evaluated requirements, and report's `specVersion` consistent.
24
+
25
+
Replacing the target specification is a breaking change because clients supporting the previous target are not required to recognize the new schema identifiers. For stable suite versions, this requires a major increment. Earlier suite tags remain available for testing earlier specification versions. Fixes can be backported when needed; publishing a new target does not promise ongoing maintenance of every older release line.
26
+
27
+
## Release tags
28
+
29
+
Each suite release has an annotated `vX.Y.Z` tag matching the root package and all plugin versions. Its GitHub release identifies the exact specification tag being targeted.
30
+
31
+
Release tags and released plugin contents are immutable; corrections require a new suite version. `main` is development state; use release tags for repeatable runs.
Copy file name to clipboardExpand all lines: plugins/agent-plugins-conformance/README.md
+3Lines changed: 3 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -26,6 +26,7 @@ This abbreviated example shows three results and their summary counts; observati
26
26
```json
27
27
{
28
28
"schemaVersion": 1,
29
+
"suiteVersion": "0.1.0",
29
30
"specVersion": "1.0.0",
30
31
"results": [
31
32
{
@@ -59,6 +60,8 @@ This abbreviated example shows three results and their summary counts; observati
59
60
}
60
61
```
61
62
63
+
`suiteVersion` records the reporting plugin's version to help investigate saved results; `specVersion` identifies the specification being tested, and `schemaVersion` identifies the report format. Older reports may omit `suiteVersion`.
64
+
62
65
Each object in `results` identifies its case through `id` and `label`, explains the outcome in `detail`, and cites the relevant specification sections in `specSections`. A result object may also contain a `warning` describing a probe cleanup failure, including the probe file's path and error. This warning does not change the result's `status`.
0 commit comments