Context
app-components/agent-text-stream-quic-v1.md, lines 29-42:
uint8 MarmotAgentTextStreamQuicRoleMaskV1;
const uint8 receive = 0x01;
const uint8 send = 0x02;
const uint8 fanout = 0x04;
struct {
uint8 required_member_roles;
uint8 allowed_member_roles;
uint32 max_plaintext_frame_len;
uint32 replay_ttl_secs;
uint16 padding_bucket_bytes;
} MarmotAgentTextStreamQuicV1;
Defect
MarmotAgentTextStreamQuicRoleMaskV1 is declared as a named uint8 type but is never referenced anywhere in the document — the struct fields that should logically carry it (required_member_roles, allowed_member_roles) are typed as plain uint8 instead. This breaks the pattern every sibling component follows, where a named element type declared for a field is the type actually used in the enclosing struct — e.g. admin-policy-v1.md's MarmotAdminKeyV1 is used inside MarmotAdminPolicyV1.admins<V>, and nostr-routing-v1.md's MarmotNostrRelayV1 is used inside MarmotNostrRoutingV1.relays<V>. It reads as leftover/dead scaffolding from an earlier draft.
Failure scenario
A code generator or implementer that mechanically maps named TLS-style types to language types has no reason to attach role-mask semantics (bit validation, printable role names) to required_member_roles/allowed_member_roles, since the struct never uses the named type — increasing the chance role-bit validation is implemented ad hoc/inconsistently across implementations.
Suggested fix
Use MarmotAgentTextStreamQuicRoleMaskV1 as the declared type of required_member_roles and allowed_member_roles in the struct, matching the pattern used by sibling components.
Context
app-components/agent-text-stream-quic-v1.md, lines 29-42:Defect
MarmotAgentTextStreamQuicRoleMaskV1is declared as a nameduint8type but is never referenced anywhere in the document — the struct fields that should logically carry it (required_member_roles,allowed_member_roles) are typed as plainuint8instead. This breaks the pattern every sibling component follows, where a named element type declared for a field is the type actually used in the enclosing struct — e.g.admin-policy-v1.md'sMarmotAdminKeyV1is used insideMarmotAdminPolicyV1.admins<V>, andnostr-routing-v1.md'sMarmotNostrRelayV1is used insideMarmotNostrRoutingV1.relays<V>. It reads as leftover/dead scaffolding from an earlier draft.Failure scenario
A code generator or implementer that mechanically maps named TLS-style types to language types has no reason to attach role-mask semantics (bit validation, printable role names) to
required_member_roles/allowed_member_roles, since the struct never uses the named type — increasing the chance role-bit validation is implemented ad hoc/inconsistently across implementations.Suggested fix
Use
MarmotAgentTextStreamQuicRoleMaskV1as the declared type ofrequired_member_rolesandallowed_member_rolesin the struct, matching the pattern used by sibling components.