travel into every session, ideally merged with a project's local
AGENTS.md when both exist. Maintainer agreed:
> yes that makes sense! am working on getting this organizational
> structure better today so that worktrees etc can feel like an
> intended way of using this.
The fallback path already loaded the global file when no workspace
context existed, but dropped it silently the moment a project
AGENTS.md showed up. After this PR:
* Both files present → merged. The global block is prepended with a
labelled HTML-style fence (`<!-- global: /home/u/.deepseek/AGENTS.md -->`),
then the project block follows with its own fence
(`<!-- project (overrides global where they conflict) -->`). Order
is global-first so workspace rules read last and win "last word"
precedence with the model when they disagree.
* Only project file present → unchanged from before.
* Only global file present → unchanged from before (still acts as a
fallback). The merge framing is suppressed in the global-only case
so the prompt stays minimal.
`source_path` continues to point at the more-specific file (project
> global > nothing) because that's the path the user is likely to
edit when they want to override something.
Two tests:
* `test_local_and_global_agents_merge_when_both_exist` —
the actual #1157 scenario. Asserts both blocks are present, global
precedes project, and the merge-framing label appears between them.
* `test_global_agents_only_no_project_unchanged_fallback` — sanity
check that the global-only path doesn't accidentally inherit the
merge framing.
The pre-existing `test_load_global_agents_when_project_has_no_context`
still passes, so the global-as-fallback contract is preserved.
Refs #1157
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
LinQ
a5c4a21c9b