Comments that survive the rewrite

The agent will rewrite the plan. Your comments should still be there.

That is not a nice-to-have. It is the difference between reviewing a live plan and reviewing a ghost.

The fear is line-number rot

You leave feedback on a section. The agent owns the file. Agents do not nudge a sentence. They rewrite sections. Sometimes the whole doc. The paragraph you underlined moves. The heading you argued about disappears and comes back under a different name. If your "inline" thread was really a frozen line number or a Slack paste of yesterday's wording, you are now talking about a place that no longer exists.

The reviewer feels it first. They open the link again and hunt for their own note. The author feels it next: "which comment still applies?" The agent feels none of it unless someone pastes context back into the prompt, and paste culture is how you got here.

Sibling cuts cover plan before execute and browser-only review. Local file as source of truth is where truth lives. This post is what happens to the thread when the agent rewrites the page.

I have lost afternoons to ghost comments. A PR thread on a SHA that no longer matched. A Slack quote of a paragraph the agent deleted. A Docs comment on a pasted copy that drifted. Each time someone said "but I already left feedback." They had. On a world that left.

The emotional texture of that afternoon is familiar if you have done agent work for more than a week. Nobody is trying to erase review. The rewrite is the job. The review surface just was not built for a document that keeps replacing itself under the same conversation.

What people do instead

Paste the plan into Slack. Fast. Zero new tool. The snapshot dies when the agent rewrites. Your thread is now a chat about an old blob. Speed wins the first minute. The rewrite wins every minute after.

Comment in the IDE on the local buffer. Fine if the reviewer is already in your session. Often they are not. Buffer comments are not built for "the agent just replaced half the file and the teammate is on the hosted link." Author-only review does not fix rewrite rot for the person on the URL.

Open a PR so you can leave line comments. Familiar GitHub UI. Wrong timeline. The plan is still moving. You invent commit noise so someone can underline text that the agent will rewrite before the PR is worth merging. After-commit review is a different job. Hand off to git when the file is ready. Do not use PR line comments as a pre-git plan surface.

Screenshot the section. Somehow still happens. Guarantees the comment cannot follow the text.

Wiki paste with comments. Feels durable. Becomes a fork. Threads survive on the wrong document while disk moves. That is a sibling failure mode. Survive-the-rewrite assumes one truth and asks whether the threads on the view still make sense after a full-file rewrite.

Each substitute is good at something else. None of them assume the file will be rewritten under the same review link.

Threads on a file that keeps changing

Gander is live review for markdown an agent is still writing.

1. Watch: gander watch plan.md. Every save updates the hosted page.
2. Comment: reviewer opens the URL. Docs-style inline threads. Anchored to the doc, not a frozen Slack paste.
3. Act: @agent is still available when a comment should reach the session. The agent edits the local file. The same link updates.
4. Then: git when it is worth committing.

Same link. New revision. Threads still readable. Comments anchor to lines and survive rewrites. The agent can rewrite the whole doc; reviewers keep reading. Full loop is shipped. Before git, not instead of git.

gander watch plan.md

Hosted watch is what makes "same link" real. Local --watch reloads your preview. It does not give your teammate a URL whose threads can ride through a rewrite.

gander watch plan.md → comment → (optional @agent) → same link updates → then git.

Notice the product bet on this axis. The hosted page is not a screenshot of the plan at comment time. It is a live view of a file that keeps changing. Docs-style threads are built for that. If the thread evaporates when the agent rewrites, you are back to paste culture with nicer fonts.

I care about this more than I care about the summon syntax alone. @agent on a ghost comment is still paste culture with a prefix. The thread has to stay with the document for the summons to mean anything after a rewrite.

Why "survive the rewrite" is the cut

Review on a file an agent owns has to assume rewrites. Chat paste does not. Static line numbers do not. A PR comment on a commit the agent has already moved past does not.

Surviving the rewrite is not a claim that every edit merges perfectly, or that you will never lose a comment in an edge case. It is the design intent: anchored threads on a live doc, same URL, so the review surface tracks the file instead of freezing a moment of it.

Without that, you review ghosts. You argue about wording that left the document. You summon the agent on a section that no longer exists.

With it, the reviewer returns to the same link after a rewrite and can still read the threads. When someone means action, @agent can still sit on a thread that stayed with the doc, not on a Slack quote of a deleted paragraph.

That is the wedge fit against the shipped @agent post. That post is who the comment is for. This one is what happens to the thread when the agent rewrites the doc.

You can feel the cut when you reopen a link after twenty minutes of agent work. Either your notes are still there, still about those lines, still unresolved until the edit is obvious, or you are hunting. Hunting means the review surface lost. The agent did its job. The tool did not.

A rewrite you can feel

Lead leaves an @agent on the "blast radius" section asking for a clearer customer impact note. Agent rewrites the whole risk chapter, including that section. Lead reopens the same link on their phone. The thread is still there, still about those lines, still unresolved until the edit is obvious. Nobody hunted through Slack. Nobody asked "which version were you commenting on?" The rewrite happened. The review survived.

That feeling is the bar. If your current loop cannot do that, it is not agent-plan review. It is a snapshot with opinions attached.

I have also lived the other feeling. Same lead, same ask, Slack quote of the blast radius paragraph. Agent rewrites the chapter. Lead comes back with "did we fix the impact note?" Author scrolls a chat transcript looking for which wording they meant. Agent gets a vague paste. Rewrite two is worse than rewrite one. The comment did not survive. The work multiplied.

What this is not

Not "never lose a comment" as an absolute. Not reliability percentages. Not traction theater. Not "every comment pages the agent." Not a claim that survive-rewrite replaces git or PR review after commit.

Not the local-SoT spine. Local file as source of truth / hosted as live view is a sibling job. This essay assumes one truth and asks whether the threads on the view still make sense after a full-file rewrite.

Same product as the plan-before-execute, browser-only, early-PR, and summons posts, different cut: anchoring under rewrite pressure.

If review cannot survive the rewrite

The next time you leave inline feedback on a plan the agent may rewrite entirely, ask what you are anchoring to. A chat paste. A line number that will rot. A PR on a commit you do not want yet. Or a Docs-style thread on the live link the file already updates.

Agent-plan review is review on a document that will change under you. If the threads cannot survive that, it is not agent-plan review. It is a snapshot with opinions attached.

Leave the comment on the doc. Keep the same link. Let the rewrite happen. The threads should still be there.