Welcome to the official Zenzic Engineering Blog. Here you will find deep dives into the architecture, design decisions, and release notes for the Zenzic Markdown analysis engine. We publish articles on static analysis, documentation quality, credential scanning, and the philosophy of docs-as-code.
Stay tuned for updates on new features, tutorials on writing custom rules, and best practices for integrating Zenzic into your CI/CD pipelines to ensure your documentation remains as reliable as your code.
Zenzic v0.20.0 is the first release to expose the engine's internal Abstract Syntax Tree to the outside world. After v0.19.0 laid the AST foundations, The Extensibility Update answers a long-standing question: what if the rules I need simply don't exist yet?
With v0.20.0, you write them yourself — in plain Python, in under a minute, with zero packaging.
Zenzic v0.19.0 is arguably the most significant structural milestone for the engine since its inception. Until today, Zenzic operated entirely as a read-only static analyzer, relying on heavily optimized regular expressions to validate Markdown. With v0.19.0, we have laid the architectural foundation for a new era of document mutation and auto-fixing.
This release represents a fundamental shift in how Zenzic understands and interacts with Markdown content.
Documentation isn't just text—it's a critical interface. When users rely on your docs to deploy infrastructure, configure security policies, or integrate APIs, a "simple typo" can lead to hours of lost productivity.
In a docs-as-code workflow, documentation is code. And just like code, it has bugs. That's why we built Zenzic: a zero-config Markdown link and structural integrity auditor.
Here are 10 subtle, frustrating, and downright dangerous documentation bugs that Zenzic catches automatically in your CI/CD pipelines.
With the release of Zenzic v0.17.0, Zenzic expands its validation capabilities beyond Markdown syntax. In addition to Markdown links and assets, Zenzic can now analyze raw HTML references embedded in Markdown documents.
A common limitation of Markdown-focused tooling is that raw HTML embedded inside Markdown documents may not be analyzed with the same level of validation as native Markdown constructs. When developers embed <a> tags or <img> elements directly into their Markdown to achieve specific layouts or functionality, broken links and missing assets can remain undetected.
With v0.17.0, HTML links and images are analyzed by the same validation pipeline used for Markdown references.
Zenzic v0.16.0 "Magnetite" marks the transition from an experimental toolchain to production infrastructure. The changes in this release address three classes of problems that accumulate silently in long-running documentation pipelines: malformed configuration that allows analysis to start on an invalid basis, unused allowlist entries that widen the security perimeter without purpose, and inconsistent exception types that force CI adapters to implement defensive workarounds.
Running Tailwind CSS components inside a MkDocs Material documentation site introduces a deceptively subtle conflict. This post documents the architectural decision, the failure mode it resolves, and why we chose a pure-CSS solution over the obvious alternatives.
We spent a full development cycle building a Docusaurus adapter for Zenzic. We ran forensic audits on real Docusaurus projects. Then we deleted every line of it.
To validate the parser and snippet-analysis capabilities of Zenzic, we needed a production-grade documentation corpus. We selected the official documentation repository of Zensical, a mature and actively maintained static site generator.
The expectation was straightforward: a well-maintained documentation codebase should produce few, if any, actionable findings.
Instead, the scan surfaced a small set of defects that had survived normal review processes. None were catastrophic, but all had user-facing consequences ranging from copy-paste failures to broken navigation and accessibility regressions.
This article examines the findings and explores why documentation quality often requires deeper analysis than conventional Markdown validation.
Zenzic v0.10.0 introduces a massive performance upgrade with a new Async Network Engine, alongside two architectural changes designed strictly for the CI/CD pipeline: Native GitHub Annotations and Destructive Rule Filtering.
These features are not aesthetic. They are built to solve three specific operational bottlenecks: network-induced CI flakiness, context switching during Pull Request reviews, and the high friction of adopting static analysis in legacy documentation repositories.
In modern CI/CD pipelines, security and performance should be structurally bounded, not just empirically observed. Traditional documentation linters and credential scanners often fail when operating at scale or under adversarial conditions. The primary failure mode is ReDoS (Regular Expression Denial of Service).