Skip to content

[BUG] apm compile --watch regenerates GEMINI.md when targets is [claude, cursor] — regression of #1019 in watch code path #1345

@siewers

Description

@siewers

Describe the bug
apm compile --watch regenerates GEMINI.md on every triggered recompile, even when apm.yml's targets field excludes Gemini. The non-watch path (apm compile) correctly omits GEMINI.md for the same project, which suggests the family-collapse fix from #1019 / #1074 was applied to the one-shot compile path but not to the watcher's recompile loop.

To Reproduce

  1. Create a fresh APM project with apm.yml:
    name: Repro
    version: 1.0.0
    targets:
    - claude
    - cursor
  2. Add any .apm/instructions/*.instructions.md file.
  3. Remove any pre-existing GEMINI.md: rm GEMINI.md (Windows: Remove-Item GEMINI.md).
  4. Run apm compile — verify GEMINI.md is not generated. Output reports only "Generated 2 AGENTS.md files" / "Generated 2 CLAUDE.md files".
  5. Run apm compile --watch. On the initial watcher emission, GEMINI.md is generated at the repo root.

Expected behavior

apm compile --watch should produce identical output to apm compile. Since Gemini is not in targets, GEMINI.md should not be generated by either invocation.

Actual behavior

GEMINI.md is generated by --watch (as a 5-line @./AGENTS.md redirect stub) but not by plain apm compile. The two paths diverge.

Environment

  • OS: Windows 11 Enterprise 10.0.26100
  • APM Version: 0.13.0
  • Shell: PowerShell 7

Additional context

#1019 identified the root cause for the non-watch path:
_resolve_compile_target() in src/apm_cli/commands/compile/cli.py collapsed any multi-family target list (e.g., claude + cursor) into "all", and should_compile_gemini_md() in src/apm_cli/core/target_detection.py returned True for "all".
#1019 (closed 2026-04-29) and #1074 (closed 2026-04-30) appear to have fixed this for the one-shot compile path.

This report observes the same symptom in the --watch recompile loop in 0.13.0, suggesting the watcher invokes a parallel code path that was not updated by the #1019 / #1074 fixes. Likely fix: route the watcher's internal compile call through the same target-resolution function that the one-shot path now uses.

Related issues

Metadata

Metadata

Assignees

No one assigned

    Labels

    type/bugSomething does not work as documented.

    Type

    No type

    Projects

    Status

    In Progress

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions