Add --category support to apm marketplace package add and set

[vicente-pastor-epam]

Summary

Expose marketplace package categories through the apm marketplace package add
and apm marketplace package set commands.

Problem

The marketplace manifest supports category and tags on package entries, and
APM emits both in marketplace output when present. The CLI already exposes
--tags, but does not provide --category, forcing maintainers to edit
apm.yml manually for categories.

Categories should be supported through the same CLI workflow as tags.

Marketplace categories are catalog-owned metadata. They may intentionally differ
from a package's own category so each marketplace can apply its own discovery
taxonomy without changing the source package.

Proposed change

Add --category TEXT to:

• apm marketplace package add
• apm marketplace package set

Validate non-empty values with the existing marketplace schema and persist the
category on the target marketplace.packages[] entry, independently of any
category declared in the source package manifest.

Acceptance criteria

• Both commands accept --category.
• Invalid or blank categories fail with an actionable error.
• The field is persisted in marketplace.packages[].
• apm marketplace check and apm pack preserve and emit category and tags.
• Command help and tests cover the new option.

[github-actions]

Triage decision

accept

Proposed labels

theme/governance
area/marketplace
area/package-authoring
type/feature
status/accepted
priority/low

Milestone

null

Suggested next action

Add --category TEXT to apm marketplace package add and apm marketplace package set, validate non-empty values, persist on marketplace.packages[], and ensure apm marketplace check and apm pack preserve the field -- following the existing --tags implementation as the model.

Suggested issue comment

Thank you for the well-structured request with clear acceptance
criteria.

This is a natural extension of the existing `--tags` flag: the
marketplace manifest already supports `category` on package entries,
and APM emits it in output when present, but there is no CLI path to
set it without hand-editing `apm.yml`. Adding `--category TEXT` to
`apm marketplace package add` and `apm marketplace package set` closes
that gap.

The acceptance criteria you listed are the right ones. A good starting
point is to look at how `--tags` is wired in those two commands and
follow the same pattern for `--category` (schema validation, persist on
`marketplace.packages[]`, preserve through `apm marketplace check` and
`apm pack`).

If you would like to contribute this, the CLI entry points live in
`src/apm_cli/commands/marketplace/`. Command help and a test covering
the new flag would make the PR review straightforward. Happy to help
with design questions along the way!

Per-lens notes (collapsed)

DevX UX Expert -- User-Need Reviewer

The user need is real and narrow: marketplace maintainers who want to
set category today must edit apm.yml manually, while the
analogous --tags flag is already a first-class CLI option. The
symmetry argument is strong and the scope is tight. The request maps
directly to the marketplace package authoring surface and follows the
npm/pip mental model where all metadata fields are manageable via the
CLI without hand-editing config files. Acceptance criteria are well-
formed and implementation-ready.

Supply Chain Security Expert -- Risk-Surface Reviewer

This touches area/marketplace and area/package-authoring. Category
is catalog metadata; it carries no trust-model, integrity, or signing
implication. The change is additive (new optional field on an existing
command), does not touch lockfile hashing, and does not introduce a
new execution surface. No security or governance risk elevation beyond
the inherent theme/governance of marketplace catalog taxonomy
management.

OSS Growth Hacker -- Contributor-Tone Reviewer

vicente-pastor-epam has author_association: NONE. The feature
request is well-organized with a problem statement, proposed change,
and acceptance criteria -- above average for a first interaction. The
reply is warm, validates the design, names the model to follow
(--tags), and points to the exact code location. It invites a
contribution while offering design support, which is the right tone
for a capable contributor who already understands the codebase.

Python Architect -- Architecture Reviewer

Not activated -- the feature is additive (new flag on two existing
commands following an established pattern); no cross-cutting design
decision is required. The --tags implementation is the template and
the change is confined to the marketplace command module.

Doc Writer -- Documentation Reviewer

The new --category flag on two marketplace commands will need a
docs update in the CLI reference and the marketplace authoring guide.
However, the docs work is implied by the PR rather than requiring a
design decision now, so area/docs-site was pruned to stay within
the 6-label cap; the implementing PR's doc checklist will cover it.
The suggested comment wording is grounded in the user vocabulary used
in the marketplace guide ("category", "tags", "marketplace.packages[]").

APM CEO -- Triage Arbiter

Clear accept. The feature is narrow, well-scoped, and follows an
established CLI pattern. theme/governance is the closest mega-theme
for marketplace catalog taxonomy management; the three available
themes do not have a perfect fit, but governance covers the catalog-
ownership model described in the issue. priority/low because this
is a convenience improvement with an easy workaround (hand-edit). No
open milestone; rides the next release. The contributor invitation
and --tags-as-model pointer should make this an easy PR to land.

{
  "decision": "accept",
  "decision_detail": "",
  "theme": "theme/governance",
  "areas": ["area/marketplace", "area/package-authoring"],
  "type": "type/feature",
  "status": "status/accepted",
  "priority": "priority/low",
  "preserved_labels": [],
  "milestone": null,
  "next_action": "Add --category TEXT to apm marketplace package add and set, following the --tags implementation as the model, with schema validation and persistence on marketplace.packages[].",
  "comment_markdown": "Thank you for the well-structured request with clear acceptance criteria.\n\nThis is a natural extension of the existing --tags flag: the marketplace manifest already supports category on package entries and APM emits it in output when present, but there is no CLI path to set it without hand-editing apm.yml. Adding --category TEXT to apm marketplace package add and apm marketplace package set closes that gap.\n\nA good starting point is to look at how --tags is wired in those two commands and follow the same pattern for --category. The CLI entry points live in src/apm_cli/commands/marketplace/. Command help and a test covering the new flag would make the PR review straightforward. Happy to help with design questions along the way!"
}

---

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 · 135.3 AIC · ⌖ 11.2 AIC · ⊞ 9.2K · ◷

[WilliamK112]

I can take this. I verified the issue is accepted and unassigned, and I found no overlapping open PR. I will follow the existing --tags path for both apm marketplace package add and set, add blank-value validation and persistence coverage for marketplace.packages[].category, update the relevant CLI/authoring docs, and run the focused tests plus repository checks before opening a PR. AI assistance disclosure: I am using OpenAI Codex to help inspect, implement, and validate the change, and I will review the final diff and evidence.