Make generated-code upgrades reviewable by construction

The next time a gRPC generator upgrade rewrites most of a pull request, treat the churn as a reproducibility check rather than a line-by-line review. Pin every generator and plugin version, regenerate in CI, and fail if the working tree changes. Then put the schema/config change in one commit and the mechanical regeneration in another. Reviewers can concentrate on the inputs and compatibility result while still retaining the generated output in version control. If this is Protobuf, a buf breaking check against main would add a much stronger signal than a huge generated diff; marking generated paths in .gitattributes can also collapse them in GitHub without hiding them entirely.

An actionable experiment is to try this structure on the next generator bump and record three numbers: total changed lines, non-generated changed lines, and minutes to approve. The useful follow-up question is whether generated artifacts genuinely need human review, or only proof that a pinned command reproduces them exactly.

• Buf: reproducible code generation
• Buf: detecting breaking changes
• GitHub: customize how changed files appear

Put a guardrail around live NATS consumer edits

Because JetStream consumer filters are editable while clients remain attached, a small runbook could make this convenient behaviour safer. Before an edit, capture the consumer configuration and delivery counters; after it, publish one uniquely identified probe message to each newly included subject and one to a newly excluded subject. Confirm the former arrive, the latter does not, and num_ack_pending or redelivery counts do not jump unexpectedly. This tests the semantic change rather than merely trusting that the CLI accepted several --filter flags.

It is also worth checking the permissions model before normalising multi-filter consumers. NATS documents a subtle distinction: a single filter can participate in a filter-specific create subject, while multiple filters use a broader consumer-create API subject. A useful follow-up is whether the current account permissions are intentionally broad enough for that difference.

• NATS JetStream consumer configuration
• NATS consumer management
• NATS monitoring endpoints

Define a Markdown portability fixture

Markdown export is becoming infrastructure between people, documentation tools, and agents, but “exports Markdown” is too vague to be a reliable contract. Create one short torture-test document containing nested numbered lists, a table, fenced code, task boxes, links, an image, and a callout. Run it through the tools used most often—Canvas or wiki to Markdown, then Markdown back to HTML or DOCX—and keep a small loss matrix showing what survives. That turns complaints about awkward hand-offs into concrete export requirements.

Pandoc makes a useful reference converter, while CommonMark gives the fixture a deliberately small baseline. Anything outside that baseline should be labelled as a chosen extension rather than assumed portable. The follow-up question is which matters more in the actual workflow: visually faithful round-tripping, or clean Markdown that an agent can reliably parse and edit.

• CommonMark specification
• Pandoc user’s guide
• GitHub Flavored Markdown specification