Skip to main content

Installation

Prerequisites and setup

Tools Overview

How the pipeline works

CLI Reference

Complete flag reference
Deploying TAHO involves real engineering work: configuring the Magnetic PeerMesh, tuning the Piranha Algorithm, writing integration logic, and evolving your setup over time. That work requires a clear record. Commit messages get written in a rush. Deployment documentation falls behind. Over time, pull requests get harder to review, new teammates take longer to get up to speed, and nobody can remember why a configuration changed three months ago. For teams running TAHO in production, that institutional knowledge isn’t just convenient, it’s critical to administering the platform as it grows and evolves. We ran into this on our own team. What started as a few scripts to clean up commits before review grew into a tool that every TAHO engineer runs on every commit. TAHO Lift is that tool, and it ships with TAHO because it solves a real problem in deployment workflows. Once you commit your deployment code, TAHO Lift reads your diff, writes a thorough commit message, and updates your repo’s documentation to match. All of that gets folded back into your original commit. No extra commits, no clutter. A single command kicks off the whole pipeline: 
lift
Two tools run in sequence on your latest commit:
  1. Inky generates an improved commit message from your diff
  2. Doc updates documentation to reflect your code changes

​
Better commits shape better teams

We noticed something on our own team: when commits explain themselves clearly, everything else gets easier. Pull request descriptions get better because they’re built on commit messages that actually describe the work. When someone runs git log six months later to figure out why a decision was made, the answer is right there instead of buried in a Slack thread. New teammates get up to speed faster because the docs match the code as it exists today. We don’t think of Lift as a linter or a style enforcer. It just raises the bar on what a “normal” commit looks like. That’s been our experience building TAHO, and we wanted to share it.

​
Our philosophy

Passive by default. We built Lift to stay out of your way. It tracks which commits it has already processed. Run it as many times as you want. It skips commits that are already done. Use -f to force re-processing or -p to get prompted first. Idempotent. Running Lift twice on the same commit gives you the same result. The tracking system in ~/.taho/lift/ records each tool’s work per commit hash, so there’s no risk of doing the same work twice. Graceful degradation. If one tool fails, the pipeline keeps going with the rest and tells you what happened at the end. A doc failure won’t stop your commit message from being improved.

​
Why we share it

Lift started as an internal tool. Every commit to TAHO goes through the same pipeline you’re reading about here: better messages, up-to-date docs, a commit history that tells the story of how the project grew. We built it because we needed it, and we share it because we think every team deserves the same thing.

​
What Lift is not

Lift is not a CI gate or a pre-commit hook. It runs after you commit, improving what’s already there. It won’t block your workflow or reject your commits. Think of it as the last part of the climb. You did the hard work, and Lift carries it to the top of the mountain.