Suggestion: persist install-time --target in apm.yml so bare apm update works

[KomTak001]

Summary

When we run apm install <package> --target <harnesses>, the chosen targets are not written into the auto-generated apm.yml. Because of that, apm update currently asks us to pass the same --target flag again.

It would be more convenient if apm update could simply refresh what was already installed, without having to remember and re-type the target list from the initial install.

Motivation

• On install, specifying --target feels natural—we are choosing which agent harnesses should receive primitives.
• On update, we usually just want to pull in newer package versions for the same setup. Re-specifying --target each time adds a small but recurring step, and it is easy to mismatch the value used at install time.

APM already documents a target resolution chain (--target > apm.yml targets: > auto-detect > fallback). It looks like the missing piece is persisting targets: into apm.yml when --target is used during apm install.

Docs reference: Install packages — Where files land

Current behavior

1. Run install with an explicit target:

   apm install example.com/org/my-package#main --target cursor,copilot,claude
   

2. apm.yml is auto-created with dependencies, but without a targets: field.

3. Later, run update without --target:

   apm update
   

4. Update may fail or ask for target disambiguation (e.g. Multiple harnesses detected), so we need to repeat the same --target value from install.

Suggested behavior

On apm install: when --target is passed, persist the resolved target list into apm.yml:

   targets:
     - cursor
     - copilot
     - claude

This would be a one-time manifest update at install time, alongside the existing dependency entries.

On apm update: read targets: from apm.yml and deploy to those harnesses. apm update would not need to modify apm.yml—only apm.lock.yaml (and deployed primitives) would change, which matches how we think about update vs install.

After that, bare apm update would be enough for the common refresh workflow.

--target on update could still override apm.yml for one-off runs, consistent with the documented resolution priority.

Scenario overview

Scenario	Suggested behavior
apm install <pkg> --target a,b	Write targets: into apm.yml
apm update when targets: is already in apm.yml	Use persisted targets; no --target flag needed
apm update	Update apm.lock.yaml and redeploy; leave apm.yml unchanged
apm update --target x	Override persisted targets for that run only

Workaround (today)

We can manually add targets: to apm.yml after the first install, or start from a template manifest that already includes targets:. That works because apm.yml targets: is already honored by the resolution chain—it is just not set automatically by the recommended one-liner install flow.

Environment

• APM CLI: 0.19.0
• OS: macOS / Windows
• Use case: installing skills/rules into multiple harnesses (cursor, copilot, claude) from a private Git host, then periodically running apm update in the same project directory

References

• Target resolution priority: apm update --help (--target > apm.yml targets: > auto-detect)
• Consumer docs: https://microsoft.github.io/apm/consumer/install-packages/
• Update docs: https://microsoft.github.io/apm/consumer/update-and-refresh/

[github-actions]

Triage Panel Verdict

Decision: Accept

Thank you @KomTak001 for this well-reasoned ergonomics improvement suggestion.

Panel Review

DevX UX Expert: The mental model of "install once, update many times" is exactly right for a package manager. The current friction -- re-typing --target on every update -- is a real barrier to adoption of the update workflow. The target resolution chain already supports apm.yml targets:, so this is closing a gap in the automated-write path, not introducing new semantics. The scenario table in the issue body is an excellent specification artifact.

Supply Chain Security Expert: Writing targets: to apm.yml is safe. The field is already schema-defined and honored by the resolution chain. No new network or trust surface.

APM CEO (Arbiter): Bounded quality-of-life improvement. The workaround (manually adding targets: to apm.yml) works today, which confirms the implementation path is clear. The suggested behavior for apm update --target x (override persisted for one run) is consistent with the documented resolution priority. Accept as a low-priority feature -- workaround available, but the fix is straightforward.

Classification

Dimension	Value
Type	type/feature
Area	area/cli
Theme	theme/portability
Priority	priority/low -- workaround available (manual targets: entry in apm.yml)

Suggested Next Action

In the apm install command handler:

• After resolving the effective target list (when --target was provided), write the resolved list as targets: into apm.yml alongside the dependency entries.
• If apm.yml already contains a targets: field (user-authored or from a prior install), do not overwrite -- only write when the field is absent.
• Add a test: apm install <pkg> --target cursor,copilot on a fresh directory -> apm.yml contains targets: [cursor, copilot].
• Update the consumer install-packages documentation to mention that --target persists to apm.yml.

---

Triage status: agentic proposal pending human ratification.
Silence is approval. Maintainers can:

• Override any label or milestone above by editing it directly --
  human edits are authoritative and will not be reverted on
  subsequent runs.
• Re-trigger triage by applying the status/needs-triage label, or
  by removing status/triaged to enroll the issue in the next
  daily sweep.

Posted by the Triage Panel workflow. See .apm/skills/apm-triage-panel for the panel skill.

Generated by Triage Panel · sonnet46 2.7M · ◷