Three Releases in One Day: Nixtla Goes Enterprise

Posted on Nov 30, 2025

30 commits. Three releases. Zero new features. The entire day was restructuring what already existed into something a CEO would show to investors.

v0.8.0: Doc-Filing Compliance

The Nixtla workspace had accumulated documentation organically. READMEs next to scripts next to architecture notes next to meeting prep. Functional but unsearchable.

Doc-Filing v3.0 compliance imposed structure: consolidated docs directory, sequential numbering, standardized naming convention. Every document got a number, a category code, and a descriptive slug. The kind of reorganization that feels like busywork until the third time you can’t find something.

Renumbering was the tedious part. Documents that had been added ad-hoc over weeks needed sequential IDs that reflected their logical order, not their creation date. Architecture docs first, then specs, then guides, then operational docs. The numbering scheme is the table of contents.

v1.0.0: The Enterprise Plugin README Standard

This is the release that changed what the repo is for.

The Enterprise Plugin README Standard defines how every plugin in the Nixtla workspace presents itself. 14 sections. 3-tier directory structure. 6 document templates. Two automation scripts.

The 14 Sections

Every plugin README follows the same structure:

  1. Title and one-line description
  2. Status badges (version, CI, coverage)
  3. Quick start (under 2 minutes)
  4. Architecture overview
  5. Prerequisites
  6. Installation
  7. Usage examples
  8. Configuration reference
  9. API documentation
  10. Testing guide
  11. Deployment guide
  12. Troubleshooting
  13. Contributing
  14. License and attribution

Fourteen sections is a lot for a plugin README. The point isn’t that every reader reads all fourteen. The point is that every question a reader has — “How do I install this?”, “What does the architecture look like?”, “How do I deploy it?” — has exactly one place to look.

The Automation

new-plugin.sh scaffolds a new plugin directory with all 14 sections pre-populated as stubs. The stubs contain TODO markers and example content. You fill in the blanks. No blank-page problem.

validate-docs.sh checks every plugin against the 14-section standard. Missing sections get flagged. Empty sections get flagged. Sections with only TODO markers get flagged. CI runs the validator on every push.

The Repositioning

Before v1.0.0, the Nixtla workspace was a developer’s workbench. After v1.0.0, it’s a business showcase. The difference is audience. A developer workbench says “here’s how the code works.” A business showcase says “here’s what this does for you, here’s proof it works, and here’s how to evaluate it.”

Max — the Nixtla CEO — is the target audience. Every structural decision filtered through one question: “Can Max show this to someone in 5 minutes and have them understand what it is?”

v1.1.0: Documentation Accuracy

The third release of the day. All 35 documents renumbered 001 through 035. Three working plugins verified end-to-end: Baseline Lab, BigQuery Forecaster, and the newly scaffolded TimeGPT Evaluator.

v1.1.0 is a patch release for a documentation-only repo. That sounds absurd. But documentation accuracy has the same failure modes as code accuracy — stale references, broken links, outdated instructions that work on the author’s machine and nowhere else. Treating docs with release discipline catches those failures before a reader hits them.

Skills Pack Phase 1

The last commits of the day scaffolded the next phase: 6 new skill directories, an architecture document, and a 4-phase rollout plan. Skills are the interface layer — how external tools invoke the Nixtla workspace’s capabilities.

Phase 1 is skeleton only. Directory structure, stub files, dependency declarations. No implementation. The scaffolding exists so Phase 2 implementation can start without architectural decisions slowing it down.

The Numbers

ReleaseWhat Changed
v0.8.0Doc-Filing v3.0 compliance, consolidated docs
v1.0.014-section standard, 6 templates, 2 automation scripts
v1.1.0001-035 renumbering, 3 plugins verified

Three version bumps in one day looks like version inflation. It’s not. Each release represents a distinct state the repo was in: organized (v0.8.0), standardized (v1.0.0), verified (v1.1.0). Squashing them into one release would hide the progression.

The day had no debugging, no new algorithms, no clever architecture. Just the grinding work of making existing code presentable. This is the work that separates a prototype from a product.