The vibe coding production review tail is just git log

It is the list of changes a reviewer has to read through to decide whether the app is safe to ship. In most AI builders that list does not exist as a structured artifact, you get a final repo or a final HTML file and you have to reverse-engineer what the agent did, which prompt produced which behavior, and where the risk crept in. In mk0r the tail is literal: the per-turn git log. Every prompt becomes a commit, every diff is reviewable in isolation, and `git show <sha>` is the unit a reviewer actually wants. That is what 'review tail' means here, the chronological list of agent turns you walk back through before production.

src/app/api/chat/route.ts line 1007 to 1013 is the whole answer. After the agent finishes streaming a turn, the server takes the raw prompt string, splits on newline, takes the first line, trims it, slices it to 120 characters, and falls back to the literal string 'Agent turn' if that produced nothing. Then it calls commitTurn(sessionKey, msg). commitTurn lives in src/core/e2b.ts at line 1759, escapes single quotes in the message, runs `cd /app && git add -A && git commit -q -m '<msg>' && git rev-parse HEAD` inside the VM, and returns the new SHA. The chat stream emits a 'version' event with the sha and message so the UI can show the new history entry, but the commit is real either way.

No. The script at src/core/e2b.ts line 1772 runs `git diff --cached --quiet` after `git add -A`. If nothing is staged the script echoes NOCHANGE and exits zero. commitTurn returns null in that case and no version event is emitted. So the review tail is dense, every entry corresponds to an actual diff. This is the right behavior for a review surface, you do not want a turn-by-turn log of every time the agent fetched something or thought out loud.

Yes. The chat panel has a history view backed by /api/chat/history, which calls getGitHistory(sessionKey, 50) at src/core/e2b.ts line 1901. That function runs `git log --format='%H|||%s|||%an|||%aI' -n 50` inside the VM and returns an array of {sha, message, author, createdAt, isActive}. The active turn is the entry whose sha matches activeIndex in the historyStack persisted to Firestore. Click any entry to undo to that point. This is the same data a terminal git log would show, just in the product UI.

Three honest gaps. First, the commit author is the VM's default git identity, not your name, so you cannot tell turns apart by user. Second, the commit message is only the first line of your prompt, so a multi-paragraph instruction loses everything past the first newline once truncated to 120 chars. Third, the per-session repo is local to the sandbox; there is no continuous push to a remote, so if you want a durable artifact for an external reviewer you need to deploy the repo somewhere that captures the log. None of these are deal-breakers for a self-review on the way to production. They do mean the review tail is a starting point, not a compliance log.

It is not framed that way. The intent of commitTurn is iteration-time history, fast undo, and honest blame for which prompt produced which file change. But the artifact you get is exactly what an audit log of a code-generating system would want, an ordered record of inputs and the diffs they produced. If you treat it as the start of a production review rather than a finished compliance trail, it is the most useful thing in the project.

The streamed-HTML path is the other generation mode in this same product (Quick mode). It is great for a one-shot mobile demo. It does not give you a per-turn diff because there is no repo, just a fresh HTML document each time. For a production review you want VM mode, which is what the commit log applies to. The picking-mode question is in src/core/e2b.ts and the chat route. Quick mode is the right tool when the output is the artifact. VM mode with the per-turn commits is the right tool when the process is the artifact.