Zenzic v0.24.0 → v0.26.0: The Editor Trilogy - Zenzic

Skip to content

Initializing search

PythonWoods/zenzic

Delivery Mechanisms

How-to Guides

Rule Reference & Catalog

Technical Reference

Core Architecture

Developer Documentation

Implement adapter

Release governance protocol

Write a check

Write plugin

Write ast rule

Troubleshooting

Reference

Explanation

ADR Vault

Core laws

Mdx asset rationale

Sovereign verification model

Tailwind mkdocs bridge

Governance

Blog

Zenzic v0.24.0 → v0.26.0: The Editor Trilogy

-->

Most editor integrations fail for a simple reason: they confuse immediacy with truth.

Fast feedback is not authoritative feedback. A red underline that appears in 20 milliseconds is worthless if the CI pipeline later disagrees with it. A score in the status bar is noise if it was inferred from partial state and sold as workspace truth.

Zenzic v0.24.0 through v0.26.0 was not a feature sprint. It was an architectural correction.

v0.24.0 introduced interaction.

v0.25.0 removed diagnostic drift.

v0.26.0 restored global scoring without corrupting determinism.

This is the editor trilogy: three releases that turned the VS Code extension from a reactive client into a governed execution surface.

The False Promise of "Real-Time Everything"¶

Most tooling vendors advertise the same fantasy: real-time everything, everywhere, all at once.

The pitch sounds good until you inspect the implementation boundary. A documentation graph is not a single file. A global score is not a local heuristic. A topological defect cannot be derived correctly from whatever subset of buffers happens to be open in the editor.

If the editor invents global truth from local events, it is not fast. It is wrong.

That is the architectural line we refused to cross.

The problem was not whether the extension could show diagnostics quickly. It already could. The problem was whether the extension could remain mathematically aligned with the same deterministic contracts that govern CLI and CI/CD execution.

The trilogy exists because speed without parity is decoration.

v0.24.0 — Interaction Without Governance Is a Toy¶

v0.24.0 introduced the first real editor-side execution surface: Quick Fixes, in-memory workspace edits, and interactive remediation paths exposed through the Language Server Protocol.

That step mattered, but not for the superficial reason.

The value of interactive remediation is not that the editor can modify text. Any extension can modify text. The value is that the modification is generated by the same deterministic system that will later evaluate the result.

Without that constraint, "Quick Fix" degenerates into one more convenience macro layered on top of an unverifiable rule engine.

v0.24.0 solved the first problem: the editor stopped being a passive alarm panel. It became a place where governed action could occur.

But interaction alone is insufficient. A system that can fix content interactively and still diverge from CLI policy is not powerful. It is dangerous.

Quick Fixes are useful only when the system applying them is governed by the same rules that will later judge the result.

v0.25.0 — Parity Is Not a Nice-to-Have¶

v0.25.0 addressed the failure mode that most editor integrations normalize instead of eliminating: policy drift.

Before stabilization, governance evaluation could occur at different points in different execution paths. That is enough to corrupt parity. If the CLI runs one filtering order and the editor runs another, the user no longer has one system. They have two systems sharing a brand name.

That is unacceptable in a deterministic engine.

v0.25.0 centralized governance evaluation, hardened adapter contracts, and added adapter-driven hot reloading so configuration changes affected the editor and the terminal through the same architectural path.

This was not improved DX. It was structural repair.

A diagnostic that exists in CI but not in the editor is not eventual consistency. It is architectural failure.

The trilogy's second step made the extension trustworthy. Not visually polished. Not more convenient. Trustworthy.

v0.26.0 — Global DQS Must Be On-Demand or It Becomes Fiction¶

v0.26.0 solved the hardest part: how to expose the global Documentation Quality Score inside the editor without lying.

The tempting shortcut was obvious: derive an approximate score from incremental language-server state. Many products would do exactly that and call it good enough.

It is not good enough.

The DQS is a repository-wide computation. It depends on the full graph, the full finding set, the full governance state, and the same batch semantics used by the CLI. If the editor computes a score from partial in-memory evidence and presents it as workspace truth, the number is invalid by construction.

A global score computed without a global audit is not approximate. It is invalid.

v0.26.0 fixed this by separating concerns instead of collapsing them:

the...