docs(corpus): define the event-kind corpus template

[serina-mcfall]

Summary

Adds launchpad/docs/corpus/templates/event-kind.md, the corpus template for documenting one Nostr event kind. Unlike its four sibling templates in this batch, it is not grounded in Serina's research note (which does not cover Nostr at all) but in this repository's own domain: NIP-01/NIP-29, buzz-core/src/kind.rs, and docs/nips/NIP-AM.md as a worked precedent.

Related issue

Closes #1337

Issue type

Task

---

Agent provenance

Field	Value
Harness / provider	Claude Code
Model	claude-sonnet-5
Session reference	N/A - harness does not expose a run id/URL
Initiating human	@serina-mcfall (batch dispatch brief for #1332/#1337/#1342/#1345/#1349)

Objective

Create launchpad/docs/corpus/templates/event-kind.md stating the purpose, required sections, evidence expectations and industry model for a corpus node describing one Buzz/Nostr event kind.

Impacted components

• launchpad/docs/corpus/templates/event-kind.md

Approach and rejected alternatives

Issue #1337's own DoD checklist is stale boilerplate copied from the standards-track issues (MUST/SHOULD/enforcement/policy language for a normative policy document). The real acceptance bar, from parent PRD #605 itself, is: "every template states its purpose, required sections, evidence expectations and the industry model/standard it adapts." This document is built against that sentence; the rest of #1337's checklist (one hand-authored document, schema-valid front matter, one independently maintainable idea, traceable claims, links instead of duplication, a check against the recorded revision, a clean validator run) is generic to any corpus node and is honoured regardless. This mismatch is stated explicitly in the node's own "Scope and authority" section.

Rejected alternative: treating OpenAPI or a generic "reference document" template as the industry model, the way a first instinct might for anything protocol-shaped. Rejected because event kinds are Nostr's own first-class concept with real, already-adopted specifications (NIP-01, NIP-29) and a real in-repo precedent (kind.rs, docs/nips/*.md) — reaching outside the protocol Buzz actually implements would have been the wrong model when a directly-applicable one already exists in this repository.

Verification

Command run:

cd /home/serina/Launchpad/buzz/__worktrees/task-1337-corpus-template-event-kind
python3 launchpad/project-intelligence/corpus/validate.py

Raw output:

UNVERIFIED  corpus-agents: evidence entry 1, citation 1: is a commit reference, which names no openable file
UNVERIFIED  corpus-agents: evidence entry 20, citation 1: is a graph-edge or tool-result citation, which names no openable file
UNVERIFIED  corpus-readme: evidence entry 1, citation 1: is a commit reference, which names no openable file
UNVERIFIED  corpus-standard-confidence: evidence entry 1, citation 1: is a commit reference, which names no openable file
UNVERIFIED  corpus-standard-decision-references: evidence entry 1, citation 1: is a commit reference, which names no openable file
UNVERIFIED  corpus-template-event-kind: evidence entry 1, citation 1: is a commit reference, which names no openable file
UNVERIFIED  corpus-template-event-kind: evidence entry 6, citation 1: is a graph-edge or tool-result citation, which names no openable file
UNVERIFIED  corpus-template-event-kind: evidence entry 6, citation 2: is a graph-edge or tool-result citation, which names no openable file
UNVERIFIED  corpus-template-event-kind: evidence entry 26, citation 1: is a graph-edge or tool-result citation, which names no openable file
PASS  corpus validation found no errors; 9 item(s) reported unverified

Command run:

python3 -m unittest discover -s launchpad/docs/corpus/schema/tests -p "test_*.py" -v

Raw output (last lines; full run was 27/27 ok, no failures):

test_full_fixture_passes (test_schema.ValidFixtureTest.test_full_fixture_passes) ... ok
test_minimal_fixture_passes (test_schema.ValidFixtureTest.test_minimal_fixture_passes) ... ok

----------------------------------------------------------------------
Ran 27 tests in 0.038s

OK

• Tests or checks were run and the raw output is pasted above
• The diff is confined to the scope of the linked issue
• No secrets, keys, tokens or hostnames were added to tracked files

Not verified

No real event-kind instance has ever been authored from this template, so whether its nine required sections actually produce a legible document for a real Buzz kind is untested. I also did not verify whether every Buzz-proposed kind is expected to get a docs/nips/NIP-XX.md file versus that being optional (named as a gap in the node's own Scope and omissions table, not answered). I did not run this past Codex for cross-model review -- Codex is down per known issue #1467 -- so review here is same-model adversarial self-review only, executed as a dedicated sub-agent pass that found and I fixed one Blocker (a false claim that a sibling template had already landed), two High findings (a misattributed quote, and an inaccurate NIP-29 kind-range claim), and several Medium findings (overclaimed uniformity in kind.rs's documentation density and access-control-set rationale, and an under-split FACT/INFERENCE claim about content-field conventions) before this PR was opened.

Security implications

None to the running system -- this is a documentation-only change with no code, config, or CI behavior touched. The one security-adjacent design choice inside the document itself is that "Required section 6" treats an event kind's access-control classification (author-only / p-gated / shared-gated) as something that must be read from kind.rs's actual set membership and cited as FACT, not inferred from what the kind "should" do -- called out explicitly in the node's own Evidence expectations section, because a wrong access-control claim in this corpus would misdocument who can read a kind's events.

Escalations

Real, unresolved boundary risk against sibling #1342 (interface template), not resolved here. An "interface" node describing an event kind's wire contract could plausibly belong to either this template (#1337) or #1342. #1342 is being authored in parallel by a different agent in this same batch, and its actual template text did not exist to read while this node was written. This node states its own position (event-kind owns the kind as a protocol/registry citizen -- number, NIP, tag/content shape, access control; interface owns a consumer-facing operation surface built atop one or more kinds) in its "Boundary against interface (#1342)" section, but explicitly does not and cannot bind #1342's author to the same line. If #1342 lands drawing the boundary differently, that conflict needs reconciling by a human or a follow-up pass before both templates are treated as settled.

[tucktuck101]

Review — event-kind corpus template

The domain claims are clean, line by line — which was the main risk here, since this is the one
template with a hard checkable domain. It names the right registry (crates/buzz-core/src/kind.rs),
requires the kind integer and its NIP, and gets the h/d/e tag distinction exactly right against
kind.rs and NIP-29 (NIP-01/NIP-29 verified at a pinned upstream SHA). Three findings, none about
Nostr.

Medium — the template never tells an instance author what type to declare

type is required by node.schema.json and is a closed enum. Grepping the whole post-frontmatter
body for instance type guidance returns zero hits. The only statement is a frontmatter
INFERENCE at :31-35 (confidence 0.6) saying an instance "would most plausibly take ...
interfaces-events" and then explicitly "does not decide that choice on the instance's behalf."

An evidence ledger is not instance guidance. #605's acceptance criterion — "An independent agent can
scaffold and validate one example node using only the standard/template/schema" — is therefore unmet
for the one field that hard-fails validation if guessed wrong. Sibling interface.md:225-228 already
states flatly that an event-kind instance carries type: interfaces-events. Add it to required
section 1, matching the sibling.

Medium — "uniquely among this batch's five templates" is false

:133-136 says the industry model it adapts is, "uniquely among this batch's five templates, not
drawn from Serina's research note at all."

The batch is #1332 (configuration), #1337 (event-kind), #1342 (interface), #1345 (procedure), #1349
(test-contract). I fetched the note at PR #1466's head (456 lines) and counted, case-insensitively:
interface 0, configuration 0, test contract 0, nostr 0. Only #1345 has real
coverage (Good Docs how-to, SRE runbook). So at least three of the five are not drawn from the note,
and interface.md:56-58 cites it only as corroboration ("independently frames the same point"). The
claim also contradicts your own :109-111 and :425-426, which say the sibling texts did not exist
to read.

Drop "uniquely among this batch's five templates" — the true and verified part ("not drawn from the
research note, which does not cover Nostr at all") stands on its own, and the 0 nostr hits confirm
it.

Medium — depends-on for the interface edge is the minority position, and semantically opposite

You say an interface node "should reach this node with a depends-on relationship".
interface.md:367-373 says the opposite — an interface node "may declare references toward one or
more event-kind nodes" — and justifies references precisely because it wants "no ownership or
currency dependency implied ... since the interface's contract can stay accurate even if an individual
kind's node is later revised". specification.md:250 independently uses references for the same
edge.

relationships.schema.json makes these opposite: depends-on = "source requires target to be
true/current for source's own claims to hold". Both are schema-legal, so CI cannot catch it, and an
instance author gets contradictory instructions depending on which template they open. Two of three
say references. Reconcile before both merge.

What is correct — verified against the code, not taken on trust

• crates/buzz-core/src/kind.rs is named as the registry, and it is.
• The requirement to record the kind integer and its NIP is right and is the thing that makes an
  instance checkable.
• The h tag (NIP-29 group scoping) versus d tag (addressable events describing a channel) versus
  e tag distinction is stated correctly — this is the single most commonly-botched fact about this
  codebase and you have it right.
• No invented citation anywhere in the node.

Not findings, ruled out on evidence

• Index registration: the corpus AGENTS.md and README.md both state that indexes are
  generated derived views, never hand-authored, and the ten-step "Creating a node" procedure has
  no registration step. All 26 template PRs leaving AGENTS.md untouched is correct.
• CI green at head (latest run per check); node validates clean.

Reviewed by tucktuck101's review lane. Every failing claim reported above was reproduced by me against this PR head before posting.