Making the Terminal-First IDE Even Stronger
Semantic locations, stronger review flows, clearer trust and health reporting, repo-native execution, honest polyglot intelligence, and more.
Hey folks!
Last week I published an important post about how the Terminal is the IDE now and I’ve been working on making it even better.
You see, that first post was the thesis. The terminal should not be a utility room bolted onto the bottom of an editor. It should be the place where engineering work actually stays coherent. It just makes sense.
This follow-up is about something slightly less glamorous and much more important: Making that IDE layer behave like one system instead of a pile of unrelated features.
Because that is the real test.
Anybody can ship a burst of commands and a few native windows and call it an IDE story. The harder part is preserving context across those surfaces, making trust legible, staying honest about what is actually answering a query, and meeting repos where they already are instead of inventing a second configuration universe.
So that is what the most recent hardening pass was really about. Here’s what’s up and the details of what I’ve added.
1. Make the Output Survive the Workflow
The biggest change was not one flashy feature. It was a contract.
I wanted YEN to stop flattening useful engineering output back into vague text the moment it crossed a surface boundary. If a result points at a real file and line, that location should survive through the terminal, the command palette, the review flow, and the native macOS windows.
So the system now leans much harder on one shared semantic location model: path:line[:col].
That shows up in yen ide parse --format tsv, in verify reports, in workflow reports, in the command palette search path, in yen ide pr-review, and in the merge-conflict workspace. Content hits, diagnostics, review evidence, workflow output, and conflict selections can all point back to the same kind of target instead of degrading into “open this file and good luck.”
That sounds small until you use it.
Once the location contract stays intact, the command palette stops feeling like a launcher with some extra sugar on top. It starts feeling like a terminal-first IDE control plane. A search result can still be a real action. A review hunk can still be a real place. A test failure can still be a real jump target.
That is the difference between “there is a lot here” and “this actually holds together.”
2. Upgrading Git Review without Becoming Git
I also spent a lot of time strengthening the review baseline.
That did not mean building a separate Git universe inside YEN. I still think that would be the wrong move. The CLI should stay the source of truth. But the review path needed to get more capable and less lossy.
So the current baseline is now bundled lazygit plus bundled delta as the shared diff renderer. On top of that, yen ide pr-review picked up deterministic hunk inventory and semantic hunk targets, while the macOS PR review workspace and merge-conflict workspace both learned how to stay anchored to those same repo targets.
That has a few nice and positive effects.
Focused hunk previews are better. Plain-text fallback is explicit instead of pretending it is the same thing. Selected files and hunks can keep their target identity all the way through a review flow. The PR evidence path can carry the latest verify readiness and security snapshot with it. And the merge-conflict workspace can show a delta-backed patch preview, keep the selected hunk as a real location, and hand that target off to the editor before staging.
That is exactly the division of labor I want. Keep the terminal-native review flow in the terminal. Use a richer native surface when it genuinely helps and don’t try to pretend that the native surface is replacing the terminal.
Makes sense, right?
3. Trust, Doctor, and Verify Finally Read Like One Story
Another major improvement is that repo state is much easier to inspect before something goes wrong.
YEN already had a lot of the raw ingredients: Project trust, env trust, LSP trust, share trust, workflow trust, local verify artifacts, devcontainer state, language-server status, and so on. The problem was not missing data. The problem was legibility.
That is why yen ide doctor matters.
It takes the existing sources of truth and turns them into one repo-health snapshot with project context, toolchain and version signals, trust and runtime summaries, verify readiness, security state, and clear blocker versus warning findings. By default it exits non-zero when blockers exist, and --strict can intentionally make warnings fail automation too. It is deliberately direct. A health command that only tells you that it successfully collected state is not useful.
The same principle drove the workspace trust center. yen ide trust status gives one aggregate view over the trust and runtime or session state YEN already had. yen ide trust revoke and yen ide trust reset delegate back to the owning commands instead of mutating trust state behind their backs. That keeps the control plane honest.
And then there is the verify path.
yen ide verify status is now a read-only snapshot over the latest local verify artifacts, while yen ide verify carries explicit local osv-scanner coverage. More importantly, that readiness and security state is no longer trapped inside one command. It can surface in doctor and in PR evidence previews too.
That matters because security is not a separate product. It is part of whether a repo looks ready to act on right now.
4. Meet Repos Where They Already Are
This is one of the places I care most about not getting cute.
A lot of developer tools become less trustworthy the moment they stop respecting the repo in front of them. They invent a second workflow system, a second task runner, or a second configuration universe and then ask you to keep both in your head forever.
I do not want that.
So a lot of the recent work was about making YEN better at reading the repo’s existing signals and putting them on one control plane.
yen ide workflow discover now inventories package scripts, Make targets, Just recipes, and Taskfile tasks with provenance, category, risk, and conflict visibility. yen ide workflow run --native is the explicit path for running one of those discovered tasks without pretending it is an authored YEN workflow, and it reuses the same trust, approval, timeline, and reporting plumbing as the rest of the workflow surface.
The quality surface follows the same rule. yen ide format, yen ide lint, and yen ide fix prefer repo-native tasks first, fall back narrowly when the repo already implies a toolchain, reuse the existing trust and approval model, and write dedicated quality reports instead of disappearing their behavior into a black box.
The test surface does too. yen ide test status and yen ide test run build on the same repo-native runner detection and verify artifacts instead of inventing a second language matrix just for testing. Grouped failures, rerun-failed behavior, and semantic jump targets all sit on that same baseline.
And the VS Code migration path got more serious in the same spirit. yen ide vscode inventory and yen ide vscode import now produce richer extension guidance, task and test parity notes, and deterministic local artifacts like migration-report.json and manual-cleanup.txt under .yen/vscode-import.
The common theme is simple: I want YEN to reduce ambiguity, not replace the repo with a parallel religion.
5. Honest Polyglot Intelligence > Pretend Coverage
The code-intelligence layer also got sharper, and I am happy about this one because it pushed the product further in a direction I care about a lot: Honesty.
In the first post about a Terminal-first IDE I said I do not want “smart” terminal tooling that lies. That rule matters even more once multiple languages and multiple fallback modes are involved.
So the install and fallback story is much more explicit now.
JavaScript and TypeScript share one managed baseline. Python and Go have their own managed paths. Rust points at rustup. Swift points at the Xcode or Swift toolchain. Zig expects zls on PATH. YEN does not silently blur those operational models together.
The AST side got stronger too. yen ide ast status, definition, and references now have real parser-backed fallback for Python, JavaScript and TypeScript, Go, and Swift, and the output says what is actually answering the query: python-ast, typescript-compiler-api, go-parser, or swiftc-dump-ast-json. Those results stay clearly labeled Source: ast so fallback never masquerades as live LSP.
Unsupported languages stay explicit instead of getting vague marketing support. Bun-backed JavaScript projects also stop falling off the AST path just because the runtime detection looked slightly different from the normalized JS family.
That is the kind of improvement I want from this layer.
Not bigger claims. Clearer contracts.
6. The Boring Internal Work Is Product Work Too
There was one other slice in this pass that matters even though it is much less visible from the outside: the IDE CLI modularization work.
I do not want every future IDE feature to keep piling into one giant Bash entrypoint until the safest answer becomes “please do not touch this file.” That is how products slow down. That is how regressions get stickier. That is how shipping momentum dies.
So the router and bootstrap layer stays stable in yen-cli/commands/core/ide, while the shared helpers and capability families live in sourced modules behind explicit loader-contract checks.
The user-facing CLI did not change. The implementation risk did.
If you want to feel the current shape of the terminal-first IDE layer, this is a pretty good compact path:
bash
yen ide doctor
yen ide trust status
yen ide lsp status
yen ide ast status
yen ide workflow discover
yen ide workflow run --native package:test --dry-run
yen ide format status
yen ide test status
yen ide verify status
yen ide pr-review 123 --list-hunksAnd if you are on macOS, press Cmd + Shift + P after that.
Search the repo. Open a review surface. Inspect diagnostics. Jump to a hunk. Pull up trust state. Notice how often the system can keep the location, the context, and the repo identity intact instead of making you reconstruct it by hand.
That is what this follow-up post is really about. The first post in the series was about saying the terminal is the IDE now.
This one is about making that sentence even more true.
There is still more to do. Editor handoff parity, remote parity, merge-readiness reporting, and benchmark work are all still on the table.
But the IDE layer is already better now in the ways that matter most to me: More coherent, more inspectable, more honest, and more native to the repo that is actually in front of you.
I like where we’re going together.
— 8