Skip to content

fix(context_for_task): ask each file's sensitivity once per call (live packs lost their affected tests) - #663

Merged
golimpio merged 2 commits into
mainfrom
atlas/context-sensitive-memo
Oct 14, 2026
Merged

golimpio merged 2 commits into
mainfrom
atlas/context-sensitive-memo

Conversation

@golimpio

Copy link
Copy Markdown
Contributor

What

context_for_task asks the daemon whether every node it reaches is in a sensitive file. On arm R's real requests that is 641–2,023 questions per pack, over only 109–242 distinct files. The daemon answers each one through connSession.changeSensitive → historyRootFor → workspacePool.Detect, which globs for language markers up the directory tree on disk.

On the live daemon, a pack therefore overran its 2 s graph deadline even on a warm, fully resolved index. It lost its affected-tests section and the run-first line from #647, in 3 of 4 Go tasks of PLAN-462 arm R v2.

Fix: the collector remembers each path's answer for the one call. A path's sensitivity cannot change within a call. Withholding is unchanged.

Why #651's replay missed it

#651 replayed the same requests in-process, without wiring a sensitive decision. They took 0.23–0.36 s there. On the live daemon, a free probe found:

  • same request, fresh worktree at the task base, warm index: 2.5–3.4 s, walk cut at the deadline;
  • sample of the daemon during that call: the on-CPU frames are filepath.Match/glob and filesystem syscalls under changeSensitive → historyRootFor → workspacePool.Detect.

Counting sensitive calls in the replay gives 641/109 (R01), 1,132/194 (R03), 2,023/242 (R05) and 1,294/203 (R08), as calls over distinct paths.

Tests

  • TestContextForTask_AsksEachPathItsSensitivityOnce:
    • each path is asked exactly once per call, and again once on a second call (the memo lasts one call only);
    • control: the sensitive file's caller is still withheld;
    • positive control: with the memo removed by hand, it fails, because cart/cart.go is asked 4 times in one call.
  • The context, census and same-package suites pass.

After merge

Install, then replay the arm R requests on the live daemon, not in-process. Success means the run-first line is present in R-599, R-601 and R-600, with the pack well under the deadline.

🤖 Generated with Claude Code

atlas-from-plumb and others added 2 commits October 14, 2026 18:37
The walk asks whether every node it reaches sits in a sensitive file: 641 to
2,023 times per pack over 109 to 242 files on arm R's real requests. The
daemon's decision (connSession.changeSensitive) resolves the path's project on
disk each time (historyRootFor -> workspacePool.Detect -> filepath.Glob for
markers), so on the live daemon a pack overran its 2 s graph deadline even on a
warm, fully resolved index and lost its affected-tests section and run-first
line (PLAN-462 arm R v2: 3 of 4 Go packs). The in-process replays that cleared
#651 wired no sensitive decision, so they could not see it. The answer is now
remembered per path for the one call.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Plumb-Session: warm-cobra
… withheld under the memo

Review S1 (scarlet-badger): a memo returning the wrong remembered answer leaked
only the second and later nodes of a file, which the control did not check. The
test now requires every cart/cart.go node withheld (at least 2 reached) and none
of its body text in the pack. The sensitiveFor comment says which asks bypass
the memo (review NIT).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Plumb-Session: warm-cobra

@atlas-from-plumb atlas-from-plumb left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved under the owner's standing delegation. The bar is met on head 61dc7a3:

  • Independent review (scarlet-badger): round 1 asked for a stronger test (S1); after the fix, PASS.
  • Mutation: 3/3 killed. The leak mutant (a remembered answer becomes not-sensitive) is caught by the every-node-withheld check; memo-never-stores and memo-outlives-the-call are also killed.
  • CI 9/9 on 61dc7a3.
  • make verify-full-container: exit 0, 64 ok, no FAIL, at most 1 daemon, Revision 61dc7a3.
  • Up to date with main fd3d991.

@golimpio
golimpio merged commit fa1fd85 into main Oct 14, 2026
9 checks passed
atlas-from-plumb added a commit that referenced this pull request Oct 14, 2026
…665)

* fix(context_for_task): detect each directory's project once per call (PLAN-548)

After #663's per-file memo, a pack still asked the daemon's sensitive-path
decision about each of its 100-250 distinct files, and each ask resolved the
file's project with workspacePool.Detect, globbing for markers on disk. On the
live daemon the slowest arm R pack ran at 1.6-1.9 s of its 2 s graph deadline,
and another was cut in 2 of 5 reps.

Collect now attaches a tools.CallMemo to the call's context. historyRootFor
reads it and detects each directory once for that call. The memo is fresh per
call, so a marker created between two calls is seen by the second, and writes,
which never carry one, detect on every ask as before. changeSensitive stays the
one decision; workspaceFromArgs is split into detectStartDir and detectedRoot
with identical behaviour.

Tests:
- one memo per call, and a fresh one for the next call;
- a marker created mid-call is not re-detected, but the next call and an ask
  outside a call both see it;
- changeSensitive gives the same verdict with and without the memo, including
  a source in another project that is sensitive only by that project's glob.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Plumb-Session: scarlet-badger

* docs(tools): CallMemo holds directory → project-root answers only

Review NIT on #665: a second kind of lookup through the same memo would share
its key space with directories.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Plumb-Session: scarlet-badger

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
@golimpio
golimpio deleted the atlas/context-sensitive-memo branch October 15, 2026 00:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants