Stallari/plugins

Fork 0

DD-404 — Marketplace artifact taxonomy + add-on packaging #32

New issue

Open

opened 2026-06-25 05:47:21 +00:00 by piersdd · 4 comments

piersdd commented

2026-06-25 05:47:21 +00:00

(Migrated from github.com)

Tracking issue (epic) for DD-404. Execution state lives here; design rationale lives in the vault — decisions/DD-404.md (+ DD-404-status.md).

State: building — taxonomy/schema/dist-sync shipped; harness Grok tile shipped v0.99.161.0. Next: harness installer sync, Marketplace IA ratification, bundle install-unit support.

Sub-issues are added as phases become active.

This was generated by AI during triage.

Acceptance criteria

Epic-level completion criteria for the DD-404 tracking issue. This is not a single dispatchable unit — the atomic, ≤10-file work lives in per-phase sub-issues (added as phases activate). This section records epic done-ness and clears the /flow acceptance-criteria linter; do not dispatch this issue as one SVD unit (it would breach the scope ceiling).

Taxonomy / schema / dist-sync shipped.
Harness Grok tile shipped (v0.99.161.0).
Harness installer sync shipped.
Marketplace IA ratified.
Bundle install-unit support shipped.
All DD-404 phase sub-issues opened, shipped, and closed.
DD-404-status.md reflects the epic complete and DD-404 moves off building.

Blocked by

None - can start immediately (epic; remaining phases carry their own blockers).

**Tracking issue (epic) for DD-404.** Execution state lives here; design rationale lives in the vault — `decisions/DD-404.md` (+ `DD-404-status.md`). **State:** building — taxonomy/schema/dist-sync shipped; harness Grok tile shipped v0.99.161.0. Next: harness installer sync, Marketplace IA ratification, bundle install-unit support. Sub-issues are added as phases become active. --- > *This was generated by AI during triage.* ## Acceptance criteria _Epic-level completion criteria for the DD-404 tracking issue. This is **not** a single dispatchable unit — the atomic, ≤10-file work lives in per-phase sub-issues (added as phases activate). This section records epic done-ness and clears the `/flow` acceptance-criteria linter; do **not** dispatch this issue as one SVD unit (it would breach the scope ceiling)._ - [x] Taxonomy / schema / dist-sync shipped. - [x] Harness Grok tile shipped (v0.99.161.0). - [ ] Harness installer sync shipped. - [ ] Marketplace IA ratified. - [ ] Bundle install-unit support shipped. - [ ] All DD-404 phase sub-issues opened, shipped, and closed. - [ ] `DD-404-status.md` reflects the epic complete and DD-404 moves off `building`. ## Blocked by None - can start immediately (epic; remaining phases carry their own blockers).

piersdd commented

2026-07-24 03:04:14 +00:00

(Migrated from github.com)

State: Read-only pre-merge sanity pass on PR #33 (branch feat/add-on-provisions-scopes) complete. The add-on admission gate enforcement matches the PR description — no discrepancies found.

Attempted: Ran git diff origin/main...HEAD --stat (3 files, +196/-161), then read the full diffs of scripts/build-catalog.js, schemas/stallari-add-on.schema.json, and schemas/catalog-entry.schema.json against origin/main, plus the PR body via gh pr view.

Evidence:

scripts/build-catalog.js: assertAddOnAdmission() (new, ~55 lines) enforces first-party-only (author_type !== "first-party" fails), scope format + membership in REVIEWED_ADDON_SCOPES (workload.trigger, hitl.approve, status.read, inference.invoke), and a subset check that every provisions_auth[].scopes entry is present in provisions_scopes. Wired into main() right after schema validation, scoped to type === "add_on", throws on violation (fails the build before R2 upload) — matches the PR's "CI fail-fast mirror of the registry worker" claim.
addOnToCatalogEntry() now carries provisions_scopes through into the served catalog entry (build-catalog.js:666-669).
schemas/stallari-add-on.schema.json: provisions_scopes added to required (line 7) and defined (line 107) with a description documenting the identical subset invariant; schemas/catalog-entry.schema.json gained a matching provisions_scopes array property. The bulk of the add-on schema's 288-line diff is pure key-reordering/restructuring noise, not a second behavioral change.
No test/build run performed — this was a read-only diff review only, not an execution check.

Risk: None identified in the diff itself. The one gap is that this pass didn't execute the catalog build or its test add-on fixtures (the PR body claims these were run manually — "Clean build = 70 entries" — but that wasn't independently re-verified here).

Decision: Diff review supports merging PR #33 as-is — does the maintainer want CI to run first (build/tests), or is this sanity check sufficient to proceed straight to merge?

**State:** Read-only pre-merge sanity pass on PR #33 (branch `feat/add-on-provisions-scopes`) complete. The add-on admission gate enforcement matches the PR description — no discrepancies found. **Attempted:** Ran `git diff origin/main...HEAD --stat` (3 files, +196/-161), then read the full diffs of `scripts/build-catalog.js`, `schemas/stallari-add-on.schema.json`, and `schemas/catalog-entry.schema.json` against `origin/main`, plus the PR body via `gh pr view`. **Evidence:** - `scripts/build-catalog.js`: `assertAddOnAdmission()` (new, ~55 lines) enforces first-party-only (`author_type !== "first-party"` fails), scope format + membership in `REVIEWED_ADDON_SCOPES` (`workload.trigger`, `hitl.approve`, `status.read`, `inference.invoke`), and a subset check that every `provisions_auth[].scopes` entry is present in `provisions_scopes`. Wired into `main()` right after schema validation, scoped to `type === "add_on"`, throws on violation (fails the build before R2 upload) — matches the PR's "CI fail-fast mirror of the registry worker" claim. - `addOnToCatalogEntry()` now carries `provisions_scopes` through into the served catalog entry (build-catalog.js:666-669). - `schemas/stallari-add-on.schema.json`: `provisions_scopes` added to `required` (line 7) and defined (line 107) with a description documenting the identical subset invariant; `schemas/catalog-entry.schema.json` gained a matching `provisions_scopes` array property. The bulk of the add-on schema's 288-line diff is pure key-reordering/restructuring noise, not a second behavioral change. - No test/build run performed — this was a read-only diff review only, not an execution check. **Risk:** None identified in the diff itself. The one gap is that this pass didn't execute the catalog build or its test add-on fixtures (the PR body claims these were run manually — "Clean build = 70 entries" — but that wasn't independently re-verified here). **Decision:** Diff review supports merging PR #33 as-is — does the maintainer want CI to run first (build/tests), or is this sanity check sufficient to proceed straight to merge?

piersdd commented

2026-07-24 03:10:18 +00:00

(Migrated from github.com)

① State: Read-only housekeeping review of origin/main's 3 newest commits — no source files modified this session.

② Attempted: Ran git log --stat -3 origin/main and reviewed the diffs of 4b21440 (#38, "backfill catalog domain scope", closes #35), 23ec368 (#37, "tighten catalog entry schema", closes #36), and ecd8776 (schema mirror of pack-spec 4.14.0's fleet-operator → fabric-operator rename, ADR-0096/DD-390).

③ Evidence:

4b21440 — touches schemas/catalog-entry.schema.json, scripts/build-catalog.js, scripts/domain-scope.test.js, scripts/catalog-entry.schema.test.js, and backfills granularity.domain_scope on 5 catalog entries: gmail-blade-mcp.json, home-assistant-blade-mcp.json, mastodon-blade-mcp.json, syncthing-blade-mcp.json, tailscale-blade-mcp.json.
23ec368 — schema tightening touching 61 files, mostly one-line additions across plugins/tools/*.json.
ecd8776 — pack-spec 4.14.0 rename mirror, unrelated to the catalog-entry schema work.

④ Risk: None from this session (no writes). Residual note on the repo state: #38's linked issue (#35, "Backfill granularity.domain_scope across 158 catalog tools (5 blade catalogs)") is Done and its own title already scopes the work to "5 blade catalogs," so the 5-entry backfill appears complete by design, not partial — flagging only because it wasn't independently re-verified this session.

Decision: No action needed against #32 itself — this session's investigation didn't touch DD-404/marketplace-taxonomy scope. Posting here per the CONV-42/DD-434 driving-issue resolution ladder (no branch-embedded issue ref, no open PR on wip/catalog-notes, single in-progress board card = #32) for continuity rather than opening a separate issue. If a full-catalog domain_scope coverage audit is wanted beyond the 5 backfilled entries, that would be a new ready-for-triage issue, not a #32 follow-up.

**① State:** Read-only housekeeping review of `origin/main`'s 3 newest commits — no source files modified this session. **② Attempted:** Ran `git log --stat -3 origin/main` and reviewed the diffs of 4b21440 (#38, "backfill catalog domain scope", closes #35), 23ec368 (#37, "tighten catalog entry schema", closes #36), and ecd8776 (schema mirror of pack-spec 4.14.0's fleet-operator → fabric-operator rename, ADR-0096/DD-390). **③ Evidence:** - `4b21440` — touches `schemas/catalog-entry.schema.json`, `scripts/build-catalog.js`, `scripts/domain-scope.test.js`, `scripts/catalog-entry.schema.test.js`, and backfills `granularity.domain_scope` on 5 catalog entries: `gmail-blade-mcp.json`, `home-assistant-blade-mcp.json`, `mastodon-blade-mcp.json`, `syncthing-blade-mcp.json`, `tailscale-blade-mcp.json`. - `23ec368` — schema tightening touching 61 files, mostly one-line additions across `plugins/tools/*.json`. - `ecd8776` — pack-spec 4.14.0 rename mirror, unrelated to the catalog-entry schema work. **④ Risk:** None from this session (no writes). Residual note on the repo state: #38's linked issue (#35, "Backfill granularity.domain_scope across 158 catalog tools (5 blade catalogs)") is Done and its own title already scopes the work to "5 blade catalogs," so the 5-entry backfill appears complete by design, not partial — flagging only because it wasn't independently re-verified this session. **Decision:** No action needed against #32 itself — this session's investigation didn't touch DD-404/marketplace-taxonomy scope. Posting here per the CONV-42/DD-434 driving-issue resolution ladder (no branch-embedded issue ref, no open PR on `wip/catalog-notes`, single in-progress board card = #32) for continuity rather than opening a separate issue. If a full-catalog domain_scope coverage audit is wanted beyond the 5 backfilled entries, that would be a new `ready-for-triage` issue, not a #32 follow-up.

piersdd commented

2026-07-25 06:59:34 +00:00

(Migrated from github.com)

Labelled needs-triage: this issue was open with no state label at all, which breaks the invariant that an open issue carries exactly one state label (or epic). Applying the neutral default rather than guessing a state — it needs a human to route it.

Context for whoever triages: the add-on admission gate landed today via Groupthink-dev/stallari-registry-infra#26 (canonical gate) and #33 (catalog-build fail-fast mirror, carrying provisions_scopes). If those discharge part of this issue's DD-404 scope, it may be narrower than when it was filed.

Labelled `needs-triage`: this issue was open with **no state label at all**, which breaks the invariant that an open issue carries exactly one state label (or `epic`). Applying the neutral default rather than guessing a state — it needs a human to route it. Context for whoever triages: the add-on admission gate landed today via Groupthink-dev/stallari-registry-infra#26 (canonical gate) and #33 (catalog-build fail-fast mirror, carrying `provisions_scopes`). If those discharge part of this issue's DD-404 scope, it may be narrower than when it was filed.

piersdd commented

2026-09-04 00:37:34 +00:00

(Migrated from github.com)

This was generated by AI during triage.

Triage: relabelled `epic`

The body says this is not a single dispatchable unit, and no DD-404 sub-issues exist in this repo (search DD-404 returns only #32). It is an undecomposed umbrella: per CONV-40 epic exemption it carries epic, is never dispatched as a unit, and its state lives on children. Next act is a DD-404 /to-tickets pass (operator), attaching each phase as a formal sub-issue. Open question the pass must answer: whether registry-infra#26 + plugins#33 already discharge part of the scope.

> *This was generated by AI during triage.* ## Triage: relabelled `epic` The body says this is not a single dispatchable unit, and **no DD-404 sub-issues exist** in this repo (search `DD-404` returns only #32). It is an undecomposed umbrella: per CONV-40 epic exemption it carries `epic`, is never dispatched as a unit, and its state lives on children. Next act is a DD-404 `/to-tickets` pass (operator), attaching each phase as a formal sub-issue. Open question the pass must answer: whether registry-infra#26 + plugins#33 already discharge part of the scope.

This discussion has been locked. Commenting is limited to contributors.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

Stallari/plugins#32

No description provided.

Rows
Columns

DD-404 — Marketplace artifact taxonomy + add-on packaging #32

Acceptance criteria

Blocked by

Triage: relabelled epic

Triage: relabelled `epic`