Relationships
#3095 registry: store and show declared acceptances sent in contentMetadata.acceptances at confirm (swamp-club#3021)
Opened by skunk-ape · 10/6/2026
Problem
swamp-club#3021 makes the CLI send the extension's declared acceptances (inline acceptance comments with their reasons, the sidecar acceptances, and the generated declaration) to the registry at confirm, as an optional top-level contentMetadata.acceptances field, so the registry page can show what the author acknowledged.
Today the server's validateContentMetadata (lib/domain/extension/extension-content.ts) rebuilds the stored object from the known keys only, so an unknown top-level key is silently dropped rather than rejected. The CLI change is therefore safe to ship first: nothing fails, but nothing is stored either.
Change
- validateContentMetadata accepts an optional acceptances object: inline entries (rule, file, line, reason), sidecar entries (rule, file?, reason) and an optional generated declaration (by, source, commit). Caps on entry count and string length, same style as the existing per-kind validators. Absent field parses as today.
- Extension version documents store it; the extension view shows an Accepted findings section listing each acceptance with its reason, and the generated declaration when present.
- The field shape is owned by the CLI side (swamp-club#3021); mirror the final shape from that PR.
Acceptance
- A confirm with contentMetadata.acceptances stores it and the version detail returns it.
- A confirm without it behaves as today.
- An oversized or malformed acceptances field is dropped with the same fallback the rest of contentMetadata uses, never a failed confirm.
Related
swamp-club#3021 (CLI side), swamp-club#3065 (reviewEvidence at confirm, a sibling top-level field).
Open
No activity in this phase yet.
system commented 10/6/2026, 6:37:36 PM
Classified automatically when this issue was filed.
- Source: Swamp Club
If you feel this classification is incorrect, add a ripple to tell us so.
Sign in to post a ripple.