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
Protocol-Commons contributions must be small, traceable, and validation-complete.
4
+
5
+
## Pull Request Spine
6
+
7
+
Every PR should:
8
+
9
+
1. Open from a focused branch for one change set
10
+
2. Explain the semantic, schema, or documentation impact
11
+
3. Include schema/example updates together when contracts change
12
+
4. Pass the required validation commands before review
13
+
5. Update release notes when the visible contract changes
14
+
15
+
## Commit Convention
16
+
17
+
Use a clear imperative subject line. Prefer conventional-style prefixes when they fit, for example:
18
+
19
+
-`docs: tighten README contract language`
20
+
-`feat: add new commons verb schema family`
21
+
-`fix: correct receipt validation example`
22
+
23
+
## Required Checks
24
+
25
+
Run the canonical validation command before opening a PR:
26
+
27
+
```bash
28
+
npm install
29
+
npm run validate
30
+
```
31
+
32
+
Run additional checks when packaging behavior changes:
33
+
34
+
```bash
35
+
npm run test:smoke:import
36
+
npm run test:smoke:pack
37
+
```
38
+
39
+
## When Schemas Change
40
+
41
+
If you change a schema or semantic contract, you must also:
42
+
43
+
- Add or update matching examples/tests
44
+
- Preserve immutability of published version directories unless the change is explicitly historical documentation only
45
+
- Review `SCHEMAS.md` and `SPEC.md` for versioning implications
46
+
- Update `CHANGELOG.md` when the externally visible contract changes
47
+
- Update `RESOLUTION.md`, provenance, or checksum artifacts if the release process requires it
48
+
49
+
## Versioning Expectations
50
+
51
+
- Treat published release lines as append-only history
52
+
- Use a new version directory for semantic changes
53
+
- Keep `v1.1.0` documented as the current in-repo line until a newer line is intentionally introduced
54
+
55
+
## Review Standard
56
+
57
+
A contribution is ready for review when a maintainer can understand the intent quickly, reproduce validation locally, and see exact schema/example/doc alignment without extra interpretation.
@@ -89,14 +111,13 @@ Every v1.1.0 Commons receipt uses the same evidence-oriented spine:
89
111
90
112
- `status`
91
113
- `timestamp`
92
-
-`agent`
93
114
- `request_hash`
94
-
-`result_hash`*(optional)*
95
-
-`result_cid`*(optional)*
96
115
- `summary`*(required on success)*
97
116
- `signature`
98
117
- `error`*(required on error)*
99
118
119
+
`result_hash` and `result_cid` are optional evidence fields. `agent` is optional and may be included when the actor/provider identity needs to be surfaced.
120
+
100
121
---
101
122
102
123
## Quickstart
@@ -196,7 +217,7 @@ The receipt contract is proof-oriented rather than transport-oriented:
@@ -208,28 +229,6 @@ The receipt contract is proof-oriented rather than transport-oriented:
208
229
209
230
These fields let consumers verify that a signer attested to a specific request hash and, when present, a specific result hash or result CID. Commons does not define transport settlement, execution proofs beyond these fields, or any x402-specific wrapping.
210
231
211
-
## Table of Contents
212
-
- [Real verbs. Real receipts.](#real-verbs-real-receipts)
0 commit comments