Wire the marketplace ingest pipeline — six plugin cards are stale, one by 27 versions

[orioltf]

Problem

This repository is a registered source on the Unic AI Artefact Marketplace — unic-agents-plugins — and nothing has pushed to it since whoever registered it did so once by hand. There is no ci/map-to-envelope.mjs and no workflow that mentions the ingest endpoint.

The catalogue it serves colleagues is therefore stale. Measured 2026-09-07 by comparing each plugin.json against marketplace_search_artefacts:

plugin	this repo	marketplace
unic-archon-dlc	0.28.0	0.1.2	27 minor versions behind
unic-pr-review	2.1.12	2.1.9	3 patches behind
unic-spec-review	0.1.11	0.1.11	current
unic-confluence	3.0.0	3.0.0	current
auto-format	0.5.15	0.5.15	current
pr-review	1.4.0	1.4.0	current, deprecated

unic-archon-dlc is the sharp one: the card every Unic colleague sees advertises 0.1.2, from before the whole two-axis redesign.

What to do

Wire the pipeline the marketplace expects, per marketplace_get_contribution_guide section B:

1. Generate an ingest token on the marketplace's detail page (owner-only, shown once, vpmk_…) and store it as the CI secret MARKETPLACE_INGEST_TOKEN.
2. Copy the current mapper to ci/map-to-envelope.mjs from https://vp.unic.com/docs/marketplace/templates/map-to-envelope.mjs
3. Add a workflow that maps and pushes the full set on each push to main. VP diffs it; re-runs are no-ops.

node ci/map-to-envelope.mjs <kind> . > body.json
curl -sS -f -X POST "https://infaz-prod-0-0-func-mktingest.azurewebsites.net/api/marketplace/ingest" \
  -H "X-VP-Token: $MARKETPLACE_INGEST_TOKEN" -H "Content-Type: application/json" --data-binary @body.json

A ready-made GitHub Action template is at https://vp.unic.com/docs/marketplace/templates/pipeline-github-action.yml

Two things to get right

provenance.author must survive. The templates send it with the push, and the guide is explicit that it is the only way the marketplace can say who changed an artefact — VP cannot resolve it afterwards. If the workflow is written by hand rather than copied, this is the field that gets dropped silently.

Push to the sidecar, not the hub. The VP hub is IP-locked; …func-mktingest… is the public ingest reachable from GitHub-hosted runners. A workflow pointed at the hub fails from CI and works from a laptop, which is the worst way to find out.

Scope

The six plugins only. All six are completeness: pointer today, which is correct for Claude Code plugins — the guide states they need no body because they are obtainable via /plugin install. Shipping their command markdown is optional.

Publishing a bare SKILL.md from this repository is a different matter and a different ticket, because a skill without its body leaves colleagues at this repo's login wall.

Acceptance criteria

Not written yet — hence needs-specs. Whoever writes them should decide what evidence counts: the marketplace card's own state line reads nothing registered · metadata only · whole skills n/total, and marketplace_search_artefacts returns the version per artefact, so "the card shows 0.28.0" is checkable by reading rather than by running anything.

[orioltf]

The canonical reference, and why it needs a person

The full documentation for this ticket is Push your catalog:

• https://marketplace.unic.com/docs/marketplace/PushYourCatalog.md
• reachable in the UI under Work Surfaces → AI Artefact Marketplace → Push your catalog (https://vp.unic.com/docs/#/marketplace/)

The body of this issue was written from marketplace_get_contribution_guide, which is that document's summary. Read the full one before implementing; it is the source of truth and this issue is not.

It cannot be fetched without a VP session. Measured 2026-09-07:

401  https://marketplace.unic.com/docs/marketplace/PushYourCatalog.md
401  https://vp.unic.com/docs/marketplace/templates/map-to-envelope.mjs
401  https://vp.unic.com/docs/marketplace/templates/pipeline-github-action.yml

The contribution guide says of the template URLs that they "need no repo access", and that is accurate but easy to misread: no repository access, yet a signed-in VP session all the same.

So this ticket is not AFK end to end. An agent can write the workflow, wire the secret and verify the result, but a person has to open those three URLs in a logged-in browser and hand over the mapper and the template — or paste them into the issue. Whoever writes the acceptance criteria should put that step where it cannot be skipped, because an agent that cannot fetch the mapper will be tempted to write one, and a hand-written mapper is exactly how provenance.author and the content block go missing.

[orioltf]

Who can generate the ingest token is an open prerequisite

The guide puts the token on "your marketplace's detail page → Ingest token panel (owner-only) → Generate token", shown once as vpmk_….

Nobody has established who owns the unic-agents-plugins marketplace registration — plausibly whoever registered it and pushed the catalogue the one time it was pushed. That is not necessarily the person doing this work, so find out before planning the rest.

The service-catalog entries around it, read 2026-09-07:

entry	id	owner
Unic Agents Plugins (component)	529	Oriol Torrent
AI Artefact Marketplace (parent service)	530	Christian Hahnloser, business owner Reto Eggimann
Unic Community Skills (sibling component)	542	Mathias Indermühle

Component 529 has no Jira project; its resolved routing sends change requests to its service owner and service/access requests to the Internal portfolio default, Jira IT.

The full documentation needs a signed-in person

Confirmed 2026-09-07 that Push your catalog is not mirrored in Confluence — a Rovo search across the AIIMPACT space returns the service page and the connector instructions, not the document. It is VP-hosted and returns 401 to an unauthenticated fetch, as do the mapper and pipeline templates.

So the reading step belongs to a person, and it is the step this ticket most depends on.

Related: this component's agentic declaration has drifted

Not this ticket's job, recorded here because this ticket makes it worse.

The agentic_capability declaration on component 529 was drafted 2026-06-10 and still reads status: needs_review. It states self_discoverable: false, and in prose: "Discovery is via the repository contents rather than a machine-readable MCP tool list or static manifest" and "The repository surface is not self-discoverable via MCP tools/list".

That was accurate in June. It is not now: this repository is a registered marketplace source whose six artefacts are returned by marketplace_search_artefacts, and wiring the pipeline makes the catalogue a live pushed one. Whoever closes this ticket should either update the declaration or open its own issue — the owner is the same person either way, and catalog_get_maintenance_guide with topic: "agentic_ready" returns the interview for it.

[orioltf]

Read against the real documentation

Push your catalog has now been read. Five things it settles, and one claim in it that is wrong about us.

The doc says this repository already reports. It does not.

Proven in production: Skill Repo (ADO), Unic Agents Plugins (GitHub) and UNIC Skills for Infrastructure & Cloud (ADO) all report this way.

The pipeline has never existed here. Searched across every branch and every commit:

git log --all --diff-filter=ADR -- 'ci/*' '.github/workflows/*marketplace*' '.github/workflows/*ingest*'
git log --all -S 'mktingest'      -S 'MARKETPLACE_INGEST_TOKEN'      -S 'map-to-envelope'
→ nothing, on any of them

What happened instead was a one-off push from outside the repository, and it can be dated from the versions that landed. unic-archon-dlc read 0.1.2 between 2026-05-23 and 2026-07-02; unic-pr-review read 2.1.9 between 2026-06-09 and 2026-06-16. The intersection is 9–16 June 2026, and the service-catalog component was registered on 10 June at 09:33 with its agentic declaration drafted the same day. So the catalogue was pushed by hand once, most likely with the ingest_local.py the doc names, on the day the component was registered.

Worth telling the marketplace owners: that production claim is inaccurate for this repository, and anyone reading it would reasonably conclude there is nothing to do here.

What the doc pins down

• The mapper kind for this repository is unic-agents — the doc names the two kinds explicitly: skills for any Agent-Skills repo, unic-agents for a Claude-plugin monorepo. No guessing needed.
• The workflow file goes to .github/workflows/marketplace-ingest.yml, from pipeline-github-action.yml, with the mapper at ci/map-to-envelope.mjs. The sidecar URL is the template's default — nothing else to configure.
• provenance is per push and has four fields — repo_url, commit, ref, author. commit becomes a link into the repo at that revision. On author the doc is sharper than the summary was: send the commit author, not whoever started the build. The mapper fills all four from the CI environment; a hand-built envelope is where this gets dropped.
• source is taken from the token, never the body. The token is scoped to one marketplace, which is where provenance comes from and why a push cannot touch another marketplace's namespace.
• The success response is a checkable acceptance criterion. A 200 returns { "source": …, "received": n, "created": n, "updated": n, "unchanged": n, "removed": n }. A first successful push from this repository should report received: 6 with updated: 2 and unchanged: 4 — unic-archon-dlc and unic-pr-review are the two stale cards.

The envelope, for reference

Required spine: artefact_id, type, name, version, description. Optional: keywords, owner, homepage, entrypoints ([{kind, ref}] where kind is install | command | agent | skill | script | provider), links, and spec — the raw native manifest verbatim, which for this repo means the whole plugin.json including nested providers.

The mapper produces all of it from .claude-plugin/marketplace.json plus each plugin.json. Do not write it by hand.

[orioltf]

Provenance settles how the catalogue got there

The earlier note called the one-off push "most likely" ingest_local.py. The marketplace records it, so it is no longer an inference. Read from marketplace_get_artefact on unic-agents-plugins/unic-confluence:

"provenance": {
  "pipeline": "local:ingest_local.py",
  "source": "unic-agents-plugins",
  "repo_url": "https://github.com/unic/unic-agents-plugins"
},
"pushed_at": "2026-06-10T21:14:53Z"

So the sequence on 10 June 2026 was two separate acts: the service-catalog component registered at 09:33 UTC, and the catalogue pushed with the local Python tool at 21:14 UTC, twelve hours later.

Registering a marketplace does not appear to ingest anything. It lists the marketplace; the artefacts arrived from that one script run. Anyone reasoning about the current state should attribute it to the push, not the registration.

Nobody can be told who did it

"versions": [{ "version": "3.0.0", "author": "", "commit": "", "commit_url": "" }]

provenance.author and commit were never sent, so the version history says a version appeared and nothing else. The doc's warning, on our own catalogue:

author is the only way a reader learns WHO changed a skill — VP cannot look it up afterwards, so a push without it leaves the history saying "a new version appeared" and nothing more.

This is the concrete reason the acceptance criteria for this ticket should check the history entry, not only that a push returned 200. A workflow can report updated: 2 and still leave the same blank author behind. The template mapper fills all four provenance fields from the CI environment; the check is that a version row afterwards carries a real author and a clickable commit.

[orioltf]

Prerequisite resolved: the token is available

The open question of who can generate the ingest token is settled. The repository owner registered this marketplace himself, and the owner-only Ingest token panel is visible to him on the Marketplaces tab. The token is in hand as of 2026-09-07.

It goes into GitHub as a repository secret named exactly MARKETPLACE_INGEST_TOKEN — Settings → Secrets and variables → Actions. Nowhere else: not in a file, not in a commit, not in an agent conversation. The workflow and mapper reference the secret by name and contain nothing sensitive themselves.

What is still blocked

The two template files, which return 401 to anything without a VP session:

https://vp.unic.com/docs/marketplace/templates/map-to-envelope.mjs
https://vp.unic.com/docs/marketplace/templates/pipeline-github-action.yml

A person has to fetch both and bring them in. The mapper especially: the documentation warns twice that a hand-written envelope is how provenance.author and the content block go missing, and a version row with an empty author is already what this repository's six artefacts carry.

The shape of the change, once those land

ci/map-to-envelope.mjs                        the template verbatim
.github/workflows/marketplace-ingest.yml      the template verbatim

Mapper kind is unic-agents — this is a Claude-plugin monorepo. The sidecar URL is the template's default, so nothing else needs configuring.

Expected first successful push: received: 6, updated: 2, unchanged: 4, and a version row afterwards carrying a real author and a clickable commit. unic-archon-dlc should move from 0.1.2 to 0.28.0 and unic-pr-review from 2.1.9 to 2.1.12.

[orioltf]

The "different ticket" this scope note points at is now rejected

The scope section above says publishing a bare SKILL.md from this repository is "a different matter and a different ticket". That ticket was #477, and it closed as rejected on 7 September 2026: unic-morning-brief-setup moves to a Unic Community Skills repository Mathias Indermühle is creating, so this repository never publishes a skill.

Nothing here changes. The scope stays the six plugins, and it is now the whole scope rather than the first half of one. Two reasons it must stay that way:

• mapSkills walks every SKILL.md in a checkout, skipping only .git and node_modules. This repository holds 41 tracked, 37 of them Matt Pocock's vendored skills. Never run the skills kind here.
• The mapper takes one kind per invocation and a push is a full set that VP diffs, so a second push with a different kind would soft-remove this one's artefacts on every commit.

[orioltf]

Read against UNICGRAPH-572's resolution

Mathias Indermühle answered UNICGRAPH-572 on 2026-09-08 and it is now Resolved. He did the check the item asked for, across all five registry sources rather than the three the doc named. Re-verified here on 2026-09-08:

source	provenance.pipeline	platform
Skill Repo	ci:map-to-envelope.mjs	ADO
UNIC Skills for Infrastructure & Cloud	ci:map-to-envelope.mjs	ADO
Drupal AI Tools	ci:map-to-envelope.mjs	ADO
Unic Agents Plugins	local:ingest_local.py	GitHub
Unic Community Skills	direct:contribution	—

Confirmed on skill-repo/create-a-unic-mcp, which records pipeline: ci:map-to-envelope.mjs with a real author and a resolvable commit_url, and on unic-agents-plugins/unic-archon-dlc, still local:ingest_local.py at 0.1.2.

Three things follow, and one of them changes this ticket.

provenance.pipeline is a better acceptance check than the counts

The field separates a piped registry from a stale one, and it is the same string on all three working pipelines. Our vendored mapper hardcodes exactly ci:map-to-envelope.mjs, so a successful push flips this source from local:ingest_local.py to that value. Read it with marketplace_get_artefact. It is one field, it needs no arithmetic, and unlike the response counts it cannot be satisfied by a push that reached the endpoint and recorded nothing useful.

The counts stay as a check too. The envelope shapes match: .claude-plugin/marketplace.json is already named unic-agent-plugins, so our install refs are byte-identical to the live ones, and unic-spec-review maps to the same 15 entrypoints it carries today. So received: 6, updated: 2, unchanged: 4 remains the right prediction.

No GitHub repository has ever pushed through a pipeline

This is the part the original item did not know. The template on that page had no production reference at all, and the "Proven in production … (GitHub)" line asserted the opposite. #478 makes this repository the first GitHub consumer of it.

That sharpens the UNICGRAPH-575 decision rather than changing it. The GITHUB_ACTOR author path has never run anywhere in production, so this push is its first real exercise. Adopting the template unmodified is still right, and the first push's recorded author is now worth reading carefully rather than assuming.

The new author guard does not cover our path — so the rule moved into AGENTS.md

Ask 2 was granted, and more strongly than requested: without a resolvable author ingest_local.py now aborts with exit 2 and names --author, instead of only warning. He also found that its main() was called without sys.exit(), so a return 2 left the process with exit 0 and a calling script read a refused push as a successful one.

That guard lives in the Python tool. Neither the vendored JS mapper nor the ingest endpoint enforces it. It matters here because the ## Marketplace ingest section documents a hand-run of the mapper for inspection, and off CI that run resolves commit, ref and author to empty strings — measured, author: "". Anyone who curls that file recreates the exact damage this ticket is about, and no guard stops them.

Fixed in 8d3e78c on the #478 branch: the section now says to read that output and never POST it, and says why. One sentence, at the command rather than in a paragraph nobody reaches.

Nothing else in #478 changes

Both vendored files stay verbatim. The pipeline string our mapper sends is already the one a real pipeline records, so there was nothing to align.

[orioltf]

Done, and one predicted number was wrong

The pipeline ran on the merge of #480 to main. Run 34279785408, success, 2026-09-08T21:18:01Z.

{"source": "unic-agents-plugins", "received": 6, "created": 0, "updated": 6, "unchanged": 0, "removed": 0, "with_content": 0, "content_truncated": 0, "repo_url_valid": true}

The updated: 2, unchanged: 4 prediction was impossible

This ticket and #478 both carried received: 6, updated: 2, unchanged: 4 as the expected first response, on the reasoning that only unic-archon-dlc and unic-pr-review had drifted. Correcting it here rather than leaving it to read as a failed push.

The artefact content_hash includes the push provenance. unic-spec-review stayed at 0.1.11 with an identical description, identical 15 entrypoints and an identical spec, and its hash still moved from 26ceaeb85516 to 8a57a105d588, gaining a second version row for the same version number. On a first pipeline push the pipeline field alone changes on all six artefacts, so unchanged: 0 was the only answer available.

The evidence was already on the board and went unused: skill-repo/create-a-unic-mcp carries three rows for the same 2026-09 version with three different content hashes. That provenance feeds the hash is inferred from those measurements, not documented — it is the only differing input between the two unic-spec-review rows.

Consequence for anyone reading a future run: unchanged will not rise above zero on this source, because every push carries a new commit. The counters are not a signal for "did the content change". received: 6 and removed: 0 remain meaningful — they say the full set arrived and no card was soft-removed.

What the acceptance evidence actually is

Three reads, all passing:

check	result
unic-archon-dlc version on its card	0.28.0, was 0.1.2, and the description is now the two-axis one
provenance.pipeline on this source	ci:map-to-envelope.mjs, was local:ingest_local.py
newest version row	author: orioltf, commit: c22d8e109dca, resolvable commit_url

provenance.ref reads refs/heads/main. All six artefacts sit at the versions their plugin.json declares. The old 0.1.2 row keeps its blank author, which is right: it is history, not a defect to overwrite.

UNICGRAPH-575 did not bite, for a reason that will not hold

The recorded author is correct here only because the person who merged is the person who wrote the change. UNICGRAPH-575 resolves provenance.author to GITHUB_ACTOR, so the first merge of someone else's PR will attribute their work to whoever pressed the button. The template stays unmodified on purpose; this is the defect staying visible.

Shipped

ci/map-to-envelope.mjs                        VP template, verbatim
.github/workflows/marketplace-ingest.yml      VP template, verbatim
biome.json                                    "!ci/map-to-envelope.mjs"
AGENTS.md                                     § Marketplace ingest

PRs #478 and #480. Deferred to #479: the Node version the vendored workflow pins against this repository's stated floor.