[FEATURE] Allow saving a default target for apm install

[SimonGelbart]

Is your feature request related to a problem? Please describe.
Today, when I install packages for the same provider, I always need to run --target MyAIProvider and this is repetitive, not natural

Describe the solution you'd like
Add a way to configure a default target (either globally or by project)
For examle

apm config set target MyAIProvider

Then apm could use that configured target automatically.

Expected behavior

• If a default target is configurated apm install uses it automatically
• Passing --target explicitly should still override the configurated default
• If no default target is configured, current behavior should remain unchanged

[github-actions]

Triage Panel Verdict

Decision: ACCEPTED (clear, bounded feature request)

Summary

Well-scoped quality-of-life improvement for users who always target the same provider. The three-case behavior (configured-default / explicit-override / no-default-unchanged) is clearly articulated and maps naturally to APM's existing config system. The feature does not change security semantics -- it only affects which target is selected when no --target flag is passed.

---

Persona panel findings

DevX UX Expert
The request is clear and the proposed shape (apm config set target MyAIProvider) fits naturally into a config subsystem. The precedence chain (explicit flag > project-local config > global config) is the right mental model. Two refinements worth considering during implementation:

1. Both a global (~/.apm/config) and a project-local (apm.yml or a .apm config stanza) default would be useful -- project-local wins over global.
2. apm config get target should echo the resolved value and which layer set it (mirrors git config --show-origin ergonomics).

OSS Growth Hacker
This is a low-friction feature that removes a repetitive tax for any user who works exclusively with one AI provider -- a common pattern. Good candidate for a first-time contributor because it is well-specified, bounded to the config and install path, and has clear acceptance criteria.

APM CEO
Accepted for a future release. Low priority (no blocker) but real user value. The implementation should reuse existing config infrastructure rather than adding a new storage surface. Verify that apm config is an existing command or plan its introduction as part of this work.

---

Triage Decision

Field	Value
Status	status/accepted
Priority	priority/low (nice-to-have QoL, no blocker)
Theme	None (local CLI UX only, no cross-cutting theme)
Area	area/cli (install command + config system)
Type	type/feature (already applied)
Milestone	Not assigned

Suggested next action: Implementer should:

1. Check whether apm config exists today or needs to be created as part of this work.
2. Decide on global-only vs. global+project-local config scope.
3. Wire --target resolution in the install path to read the config key before falling back to an error.

Thank you @SimonGelbart for the clear and actionable feature request.

---

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.2M · ◷