The agent changed the file. Why is the app still old?

Start with the process that owns the files

Ask the agent to report its physical working directory before editing. In a shell, pwd -P resolves the current directory physically rather than presenting a convenient logical path through a symbolic link. Record the result locally. Then ask which command will perform the build and what directory that command uses. A terminal opened in the correct folder does not prove that a package script, IDE scheme, container bind mount, or background process uses that folder. Follow the actual producer of the result instead of inferring it from a tab title.

On the developer's side, inspect the editor workspace and the running development server separately. An editor can open one checkout while a terminal remembers another. A server can continue serving a previous build after its launching terminal closes. If the operating system or development tool can reveal the running process's working directory, compare that observation with the agent's report. Do not paste a complete process environment into chat: it may contain credentials. The identity question normally needs the directory and executable relationship, not every variable inherited by the process.

If either path is unknown, say so explicitly. An unknown build directory is a missing fact, not evidence of a cache defect. Pause further edits long enough to connect the visible application to a source root. In the example, this immediately reveals that the agent edited the delivery worktree while the developer launched the stable checkout. The existing edit may already be correct. Repeating it in a second place would create another patch to reconcile without solving the original mismatch.

Record a revision without confusing it with the whole state

Inside a Git working tree, git rev-parse --show-toplevel identifies the repository root, and git rev-parse HEAD identifies the checked-out commit. A branch name adds context, but it is not a substitute for the commit. Branches move. Detached worktrees may have no branch name at all. Conversely, two worktrees can share a commit while carrying different uncommitted edits. The identity record therefore needs both the revision and a concise account of local state. Keep those facts together when asking another agent to continue the same Task.

Use git status --short --branch to see the branch and changed paths, and inspect the relevant diff before assuming it belongs to the current request. The Git status reference describes the index, working tree, and untracked states that this output summarizes. In particular, a clean tracked diff does not demonstrate that an untracked configuration file or ignored build input is irrelevant. You do not need to upload all such files. You need to understand which inputs the build actually consumes and protect private configuration while checking that relationship.

For a handoff, prefer a short factual record: source root, commit, branch or detached state, relevant changed paths, and the exact command last run. Include whether those edits were committed. Avoid claiming that a commit contains work that remains only in the working tree. If an agent says a fix is saved, clarify whether that means an editor buffer, a disk file, a commit, a remote branch, or a deployed artifact. Those are different durable states, and each answers a different recovery question.

Treat worktrees as separate working copies

A linked Git worktree gives a repository another working directory. It is valuable for isolating fixes and release preparation, but the directories do not share a single editable file tree. The Git worktree documentation explains how linked working trees relate to the same repository while retaining their own checked-out state. Run git worktree list --porcelain to inventory their paths and recorded revisions. Review the result before deciding that a similarly named directory is an abandoned duplicate.

In the example, the stable directory is clean on main, the delivery worktree contains a small patch, and an older experimental worktree has unrelated changes. Only the delivery patch belongs to the requested fix. Do not solve the mismatch by deleting the older directory or merging every branch blindly. First inspect whether another agent or person owns active work there. A worktree can be quiet at the instant you inspect it and still contain valuable uncommitted files. Ownership and contents matter more than the age suggested by its folder name.

When several agents run concurrently, give each intended execution an explicit source root. A shared Task description should distinguish that source root from the destination where the completed change will be integrated. If one agent is reviewing and another is editing, say which directory each may modify. This avoids an especially confusing race: a reviewer observes a diff that changes underneath its test run, then reports a result against a revision that no longer represents the files it actually tested.

Support folders that have no repository

Not every useful Task begins in Git. A user may ask an agent to organize local notes, repair a generated project, inspect exported assets, or work in a newly created directory before version control exists. A repository chooser must not turn that absence into a fictitious repository. Identify the actual folder and its purpose, then state that no Git revision is available. File-level evidence can still establish what was inspected and changed. The absence of a commit changes the evidence you can provide; it does not make the Task invalid.

For a non-Git workspace, capture the relevant relative paths, file sizes, and modification observations before making changes. Where exact identity matters, calculate hashes of the specific non-secret files involved. Avoid collecting entire home directories or dumping document contents merely to prove a root. If a build uses a manifest, record the manifest's identity and the command that reads it. Keep a separate copy before an irreversible conversion. A small, focused record is more useful than a huge archive whose provenance nobody can explain.

GrantTap's Task can remain the user's stable unit of work while different executions operate in different kinds of source folders. The product should show missing repository metadata honestly and let the user choose the correct workspace. Do not tell an agent to initialize Git solely to satisfy a selector unless the user actually wants version control. Creating a repository is a product or workflow decision, not a harmless substitute for implementing a folder-based path through the interface.

Follow the build inputs all the way to the artifact

After confirming the source root, inspect the build command's inputs. A website can read a generated content directory instead of raw Markdown. A native application can select a different target or scheme. A package can resolve a local workspace dependency to a sibling directory. A container image can be built from a context whose copied files differ from the shell's current directory. Write down the concrete relationship that matters in your case rather than assuming every file under the repository is an input.

For the delivery example, the changed Swift file belongs to the application target, but the first local build used a separate worktree's project. Pointing the build at the intended project resolves the apparent inconsistency. For a website example, editing an article body without running the content-generation step can leave a valid but outdated output directory. The correct repair is to regenerate the intended output and rebuild it. Clearing every package cache would be slower and would obscure the missing build step that actually explains the behavior.

Associate a successful build with a source revision and the relevant local modifications present at build time. If files changed during the build, retain that uncertainty rather than manufacturing a clean provenance claim afterward. A screenshot proves that a particular visible state existed; it does not independently identify the source commit. A release record can connect the screenshot, artifact hash, build command, and tested revision. That connection is what allows a later reviewer to determine whether the reported fix reached the tested application.

Distinguish source changes from delivery and deployment

There are several legitimate milestones between editing a file and a user seeing a change. A commit records source history. Pushing makes that commit available in a remote repository. A build creates an artifact. Uploading or deploying makes an artifact available through a distribution channel. Installing or opening it selects the version a user actually observes. A successful milestone does not silently imply the next one. Report the milestone that has evidence, especially when a phone still runs an earlier TestFlight build.

In a website workflow, confirm which immutable image or release directory the serving process currently uses. The source repository's main branch can be current while the process serves yesterday's image. Conversely, an emergency deployment can serve code whose provenance has not yet been reconciled with main. Inspect both identities and record the relationship. Avoid printing deployment environment values. Image identity, source revision, route health, and visible page behavior are usually enough to establish whether the intended release is serving.

The same reasoning applies to an agent integration. Updating an MCP package in a repository does not update an already running machine process. The installed package version, process start time, and active runtime can differ from the source checkout. Check those facts before describing a source merge as a delivered fix. GrantTap's Devices and delivery observations can help organize the investigation, but a connected indicator should not be interpreted as proof that every local component runs the newest source available on GitHub.

Transfer context with a destination check

A provider transfer preserves the purpose and visible conversation of a Task according to the implemented transfer contract. It does not guarantee that a destination computer has the same uncommitted files, local dependencies, permissions, or installed tools. Before allowing the destination execution to continue editing, have it identify the folder and relevant revision it actually received. Compare those facts with the source record. If the destination needs a patch or repository update, complete that step deliberately and verify the resulting files.

Use an acceptance question that can be answered from the destination itself: which source root is open, which commit is checked out, which relevant files differ, and what small read-only check confirms the expected change? A provider saying it understood the handoff is weaker evidence than that concrete response. Do not include secrets in the transfer summary, and do not instruct the destination to bypass approval settings to simplify the test. A successful continuation includes the intended policy as well as the intended code.

For the example Task, the destination Claude execution can inspect the delivery worktree and name the resend helper before running its targeted test. If it instead opens the stable checkout and cannot find the helper, the next action is to repair workspace selection. Asking it to implement the feature again would produce duplicate work. Keep the same Task and correct the execution's source relationship; the user should not have to reconstruct the entire request because the provider or computer changed.

Integrate changes by responsibility and preserve ownership

When work is ready for main, inventory candidate branches and worktree heads, then inspect their differences from the current integration base. A branch can be fully represented by a newer implementation even when an old commit is not yet an ancestor. Merge decisions need both history and behavior. Preserve later fixes when resolving conflicts, and record why an older implementation was superseded. A conflict-free merge is convenient, but it does not prove that two independently valid changes behave correctly together.

Save relevant uncommitted work before integration using the repository's established commit and authorship rules. Do not mix private generated caches, credentials, unrelated experiments, or another person's unfinished edits into a broad commit. If a worktree belongs to an active execution, coordinate access before changing its files. The safe integration target is a dedicated checkout whose source remains stable during release checks. This is particularly helpful when native UI tests take a long time and would otherwise test a moving mixture of changes.

After integration, verify that each intended branch head is represented and that no relevant uncommitted change was left behind. Then run the combined behavior checks. Once the remote main is updated, local main worktrees may still be stale and need a clean fast-forward. Do not delete all worktrees as a substitute for proving completion. A retained directory with a documented relationship to main is understandable; a deleted directory whose unique changes were never inspected is a potential loss of work.

Use a small verification ladder

Begin with a read-only check that names the expected file and source identity. Next run the narrow behavior test that would fail without the fix. Then build and exercise the affected user journey in the intended environment. Finally verify the delivered artifact if deployment or distribution is part of the request. This ordering reduces wasted work: a failed source-root check should be resolved before an expensive full build, and a failed focused test should be resolved before a production deployment.

For a UI fix, choose an observable assertion such as a label appearing, a pending row clearing after confirmation, or a button preserving the original message identifier. Avoid tests that merely search the source text for a helper name. For a release, record the exact artifact and environment where the assertion passed. If a Simulator check passes but a physical-device gate is required, state the remaining gate. Similar-looking screenshots from different builds are not interchangeable evidence, even when both applications compile from the same repository.

A useful final report is compact: changed behavior, integrated source revision, checks performed, observed artifact, and material limitation. That report lets the developer distinguish a correct patch awaiting distribution from a deployed change that failed its acceptance scenario. It also makes the next agent's job easier. Instead of repeating a vague instruction to fix the old screen, the next execution can start from the precise missing link, such as an outdated installed package or a release process still pointing at the previous image.

Keep the identity record short enough to maintain

Do not turn this investigation into a second project-management system. A five-line record beside the Task is usually enough: working directory, revision and dirty state, intended change, verification command, and artifact or deployment state. Update it when one of those facts changes. Keep detailed logs separately and link them when needed. A long narrative copied between agents becomes stale quickly; a concise record of current observations is easier to compare with what a destination execution can actually see.

The important habit is to ask which files and which result a statement refers to. Changed, tested, merged, deployed, and installed describe different relationships. Once those relationships are explicit, the supposed mystery of an agent editing invisible files usually becomes a concrete path or version mismatch. GrantTap can keep the Task coherent while you repair that mismatch. The acceptance condition remains the user's requested behavior in the intended application, supported by evidence from the correct source and artifact, rather than another successful edit in a directory nobody is running.