T-8BUZ-marketplace-targets-and-support-warnings

State: planning/proposed · Impact: high · Complexity: medium

Goal

A build renders exactly two roots, claude/ and codex/, no matter what a marketplace’s notes declare — the six other canonical targets (portable, cursor, gemini-cli, opencode, amp, copilot) are reachable per-note through ap-targets but never get a root of their own to land in. And nothing tells an editor that a field they just set will be silently dropped by a harness their marketplace targets. This task lets a marketplace declare its harness set, renders one root per declared harness, and warns in the editor where a field will not survive to a given target.

Today

Location	Role today
`solutions/agent-pants/crates/agent-adapt-core/src/export.rs#MarketplaceConfig`	`name, display_name, owner, author, default_plugin, plugins: BTreeMap<String, PluginOverrides>`; no field naming which harnesses the marketplace targets
`solutions/agent-pants/crates/agent-adapt-core/src/export.rs#ROOTS`	A fixed `[RootSpec; 2]` array (`claude`, `codex`); `export_skills` always builds both, regardless of any note’s `ap-targets`
`solutions/agent-pants/crates/agent-adapt-core/src/publish.rs#canonical_targets`	Returns all 8 canonical targets (`amp, claude, codex, copilot, cursor, gemini-cli, opencode, portable`) folded from `KNOWN_TARGETS`; only `claude` and `codex` are ever reachable through a marketplace build
`solutions/determined/experiences/agent-pants/app/components/ApBuildPanel.vue#roots`	Groups the build report’s units by `unit.root`, so it already renders however many roots the report contains — no hardcoded assumption of exactly two
`solutions/determined/experiences/agent-pants/app/components/ApTargetsControl.vue`	The per-note `ap-targets` control (all/some/none); no marketplace-level equivalent and no per-field harness-support indicator
`solutions/agent-pants/packages/agent-pants/src/commands/marketplace.ts`	Resolves `--marketplace`/config flags and calls `exportSkills` once; states explicitly that “which root a skill’s `ap-targets` admits it to” lives in `agent_adapt_core::export`, not here
`solutions/determined/experiences/agent-pants/docs/vault-layout.md`	Documents the marketplace → plugin → kind-folder → component inheritance for placement and sharing; says nothing about which harnesses a marketplace targets
`solutions/agent-pants/docs/vault/reference/harness-comparison.md`	Per-harness field support survey, researched 2026-08-08, the seed data a warning needs

Proposed

MarketplaceConfig gains ap-targets (a marketplace-level harness list, same three-state shape as a note’s ap-targets: absent means every canonical target, empty means none, named means only those). export_skills renders one root per effective target instead of the fixed claude/codex pair — turning ROOTS from a static array into a table keyed by RuntimeId, covering every canonical target that has a SkillCapability (portable becomes reachable for the first time). docs/vault-layout.md documents the marketplace → plugin → note inheritance for ap-targets the way it already documents placement. ApTargetsControl.vue (or a marketplace-page sibling) shows the inherited target set at the marketplace level. A new useHarnessWarnings() composable joins a note’s effective targets with the (not-yet-built) capability matrix and renders a callout per field the target will ignore or translate, linking to that field’s documentation entry and offering “add an override for this harness” — a field an override already covers for that target raises no warning. Warnings never block a save.

Approach

Add ap_targets: Option<Vec<String>> to MarketplaceConfig, read from the marketplace note’s frontmatter the same three-state way a component note’s ap-targets reads today, falling back to “every canonical target with a skill renderer” when the note is silent.
Replace ROOTS: [RootSpec; 2] with a table built from canonical_targets() (or from runtimes::all() once T-HLEW-harness-capability-matrix exposes it) filtered to targets with a SkillCapability renderer, each carrying its own projection_prefix, plugin_manifest_dir, and marketplace_manifest the way claude/codex do today; verify a portable root builds with no plugin manifest dialect assumption baked in.
Filter the built roots by the marketplace’s effective ap-targets from step 1.
Update docs/vault-layout.md with an inheritance section: marketplace ap-targets narrows what a build renders; a component’s own ap-targets narrows further, never widens past its marketplace’s set.
Add the marketplace-level targets control to the plugin/marketplace page, reusing ApTargetsControl.vue’s three-state UI.
Build useHarnessWarnings(note, effectiveTargets): for each set field on the note, look up its support per target (native/translated/ignored/rejected) from the capability matrix; render one callout per (field, target) pair where support is not native and no override already supplies that target, naming the harness, linking the field’s documentation entry, and offering “add an override” wired to the note’s Overrides section.
Wire the composable into SkillFieldsForm.vue and confirm a save proceeds with warnings present.

Areas

Area	Note
`solutions/agent-pants/crates/agent-adapt-core/src/export.rs`	`MarketplaceConfig.ap_targets`; `ROOTS` becomes a target-derived table; filter roots by effective targets
`solutions/agent-pants/crates/agent-adapt-core/src/publish.rs`	Expose whatever helper `export.rs` needs to resolve a marketplace’s effective target set (reuse `canonical_target`)
`solutions/determined/experiences/agent-pants/docs/vault-layout.md`	Document marketplace → plugin → note `ap-targets` inheritance
`solutions/determined/experiences/agent-pants/app/components/ApTargetsControl.vue`	Support a marketplace-level mount point, or confirm the existing component already generalizes
`solutions/determined/experiences/agent-pants/app/composables/useHarnessWarnings.ts`	Joins effective targets with the capability matrix; renders per-field warnings
`solutions/determined/experiences/agent-pants/app/components/SkillFieldsForm.vue`	Mount `useHarnessWarnings()` output as callouts near the affected fields
`solutions/determined/experiences/agent-pants/app/components/ApBuildPanel.vue`	Confirm the roots grouping renders more than two roots correctly; adjust output-root picker copy if it names “claude/codex” literally

Acceptance criteria

AC-1: A marketplace note with ap-targets: [portable, claude] builds a portable/ root and a claude/ root, and no codex/ root.
AC-2: A marketplace note with no ap-targets builds a root for every canonical target that has a skill renderer, portable included.
AC-3: Setting a Claude-only field (for example allowed-tools) on a note whose effective targets include Codex shows a warning naming Codex, linking to that field’s documentation entry, and offering “add a Codex override”.
AC-4: A field already covered by an existing per-target override for that target raises no warning.
AC-5: Saving a note with an active warning succeeds; the warning is informational only.
AC-6: docs/vault-layout.md documents the three-level ap-targets inheritance (marketplace narrows the canonical set, plugin and note narrow further).

Out of scope

Building the capability matrix’s data itself (native/translated/ignored/rejected per field per target) — T-HLEW-harness-capability-matrix; this task consumes it.
The ap-overrides frontmatter key and its merge-last render behavior — T-IIZO-per-target-overrides; this task only offers the “add an override” entry point.
Per-field documentation pages the warning links to — T-A27K-field-reference-docs-with-evidence.
Placing the Overrides section in the edit form — T-GHE3-edit-form-in-center-pane.

Dependencies

T-HLEW-harness-capability-matrix: useHarnessWarnings() reads per-field, per-target support from the matrix this task exposes; cannot render a real warning without it.
T-IIZO-per-target-overrides: the warning’s “add an override” action opens that target’s block in the Overrides section this task depends on existing.

Discovery context

From the user’s Agent Manager planning request of 2026-09-07, data-model area: “marketplace-level targets” and the warnings the user wants when a targeted harness will not honor a field. Findings in solutions/agent-pants/docs/vault/research/agent-skills-conformance.md (“Only six keys in portable output” row) and the harness divergence table in solutions/agent-pants/docs/vault/reference/harness-comparison.md, researched 2026-08-08.

Depends on

T-HLEW-harness-capability-matrix, T-IIZO-per-target-overrides

← Back to Tasks