Skip to content

Design research

Dated experiments and consumer evidence used to make OINK design decisions, without normative force.
Evidence, not a contract

Research records what was measured, with which inputs and tool versions. Results may explain a decision, but they do not override the current contracts or implementation.

Research belongs in the public Design tree when another maintainer can inspect its method, understand its limits, and repeat the relevant check. Raw agent transcripts, temporary build logs, and local absolute paths do not meet that standard.

Research map

Record Evidence
Goldmark block attributes Render-hook visibility and CommonMark container limits on the supported Hugo floor
Consumer and migration evidence A dated corpus survey plus deterministic Book migration results
Comprehensive review, 2026-08-26 Implementation, configuration, output, security, test, performance, and doc audit
Community issue and PR review, 2026-09-19 Reproductions, PR acceptance advice, and remedies for sidebar, focus, and search feedback
OINK 1.1 release review, 2026-09-20 Five runtime repairs, documentation readiness, validation evidence and publication boundaries
CLI acceptance snapshot, 2026-09-29 Executed Starter, real-site, offline, upgrade, and reproducible-archive checks; final local acceptance and public release remain separate
Visual preset acceptance, 2026-10-05 Paper/Slate local implementation, actual output and bounded browser evidence
Ink and Terminal experiment, 2026-10-05 Explicit experimental presets, design tradeoffs and real-site verification
OINK 1.2 pre-release review, 2026-10-05 Final local candidate checks, cleanup, local resources, compatibility and publication boundaries

Publication rules

A research record states its date, inputs, relevant versions, method, result, and known limits. Volatile counts are labeled as snapshots. External framework comparisons are refreshed from primary sources before publication and distilled into OINK-relevant conclusions rather than copied as a competitor catalogue.

When a result becomes a stable product choice, link it from an accepted decision. When it proposes behaviour that does not exist, move the design question to Proposals.