rivet vsix

[avrabe]

A user requested that the yaml editing is cumbersome as for a user. Wonder how we would and should do this. We should have all in common but we miss the ui for helping humans to work with

[avrabe]

Triage from the issue-fixing routine: real friction (YAML-by-hand authoring is the dominant human cost), and the framing is explicitly exploratory ("wonder how we would and should do this") — which is the right shape for design but not the shape the routine can verify before opening a PR. Deferred until an explicit "fixed when …" line is pinned.

This one is on the design-issue end of the spectrum (closer to #490's "wants a design pass before code" posture than to a single-PR bugfix), so the AC may itself be "produce a design doc that pins the surface", with the implementation AC coming on the follow-up. Two distinct slices the routine could pick up cleanly if you decide to scope it that way:

## Acceptance Criteria — option A (scoping / design issue)
- [ ] A short design note (in-repo `docs/design/vscode-extension.md` or a comment on this issue) pins: (1) which surfaces ship in v1 — schema-driven YAML completion, hover for schema-defined fields, link-target lint, "rivet add" command palette, dashboard webview, or some subset; (2) where the extension lives — this repo (`rivet-vscode/` workspace) vs a sibling repo (`pulseengine/rivet-vscode`); (3) how it shares schema metadata with the CLI (re-exports from `rivet-core`? a generated JSON schema? LSP via `rivet lsp`?); (4) packaging story (`.vsix` from CI, marketplace target).
- [ ] Decision recorded as a `decision`-type artifact in this repo so it's part of the trace graph. Refs: `#546`.

## Acceptance Criteria — option B (minimum-viable VSIX, if you'd rather start with shipping something)
- [ ] An MVP VSCode extension under (e.g.) `rivet-vscode/` that provides JSON-schema-backed completion + diagnostics for `*.yaml` files matching the rivet shape, sourced from the existing schemas in `rivet-core` (generated to JSON Schema at build time — no hand-rolled duplicate).
- [ ] A CI job builds the `.vsix` on tag and attaches it to the release (mirroring the existing release artifact flow). Marketplace publication explicitly out of scope for the MVP.
- [ ] A smoke test: opening a `rivet.yaml` fixture in `code --extensionDevelopmentPath=…` shows completions for known field names and a diagnostic on an undeclared field — captured in a CI integration test or, if that's too heavy, documented manually with a screenshot in the PR description.
- [ ] `rivet validate` and `cargo test` / `fmt --check` / `clippy --all-targets -- -D warnings` clean.
- [ ] Commit trailers: `Implements: REQ-NNN` (new REQ for the extension surface) + `Refs: FEAT-NNN` (new FEAT if you want a feature trace) + `Refs: #546`.
- [ ] **Explicitly out of scope (file separately):** LSP-based hover/go-to-definition across artifact IDs (richer, separate slice); dashboard webview reuse; marketplace publication; non-VSCode editors.

The repo-placement and CLI-extension-share questions are real and benefit from your call before either AC is locked. Worth saying explicitly which path you want.

Process side-rail (carried from every recent triage thread): https://pulseengine.eu/blog/ is still HTTP 503 (long-standing site-infra symptom flagged on #420, #468, #456, #436, #431, #422, #479, #482, #488, #490, #500, #508, #509, #516, #522, #523, #530, #532, #538, #543 — re-verified at the start of this run). The binding workflow guidance can't be consulted, so no PR will land from this triage regardless. Comment is the AC ask only.

Not implemented this run.

---

Generated by Claude Code — issue-triage agent run 2026-06-19.

---

Generated by Claude Code

[avrabe]

One could be to direct lly offer support in editing the yaml with the schema and for. The links with support on auto completion.

Otherwise I would think of some edit button in the html seve to directly modify values and an add button in the side view for artifact files or artifacts and so and then to open the editor viewer

[avrabe]

Triage from the issue-fixing routine, picking up your 2026-06-19 20:27 reply directly: two independent directions surfaced, each with an obvious done-shape. "One PR per issue, keep PRs focused" means they're separate units of work. Suggestion: keep this issue scoped to direction 1 (the VSIX framing matches the title); file direction 2 as a sibling issue (it's a rivet serve feature, not an editor-side surface).

Direction 1 (this issue) — VSCode YAML editing with schema-driven autocomplete + link-target completion. Narrowed from option B of the 2026-06-19 sketch to the two surfaces you actually named:

## Acceptance Criteria — VSIX MVP (direction 1)
- [ ] A VSCode extension under `rivet-vscode/` (workspace member) provides schema-driven completion + diagnostics for `*.yaml` files matching the rivet shape, sourced from the existing schemas in `rivet-core` — generated to JSON Schema at build time, **no hand-rolled duplicate**, no fork. The generator runs in `build.rs` (or a Cargo `xtask`) so a schema edit on the CLI side is one rebuild from being reflected in the extension.
- [ ] **Link-target completion** is the load-bearing affordance: typing into a typed link field (`satisfies:`, `verifies:`, `traces-to:`, `refines:`, …) offers completions from the project's artifact store, filtered to the types allowed as targets for that link per the existing `link-target-type` rule. Tested on a fixture project with mixed-type artifacts; the allowed-targets filter matches `rivet validate`'s output byte-for-byte (i.e. the extension never offers a completion that `rivet validate` would then reject).
- [ ] CI builds the `.vsix` on tag and attaches it to the release (mirroring the existing release artifact flow). Marketplace publication is explicitly **out of scope** for the MVP — the `.vsix` is a download-and-install asset until the marketplace call is made.
- [ ] Smoke test: opening a fixture project's `rivet.yaml` in `code --extensionDevelopmentPath=…` shows completions for known field names + a diagnostic on an undeclared field; opening a fixture artifact YAML and typing into a `verifies:` field offers the allowed-target artifact ids only. Captured in CI if tractable (headless VSCode test framework), otherwise documented manually with a screenshot in the PR description.
- [ ] Extension respects the project's `rivet.yaml` schema set — completions reflect what's actually loaded (embedded vs. on-disk, per REQ-176/177/178), not a hard-coded schema list. Verified on a fixture that overrides one bundled schema with an on-disk vendored copy.
- [ ] `rivet validate` PASS unchanged; `cargo test` / `fmt --check` / `clippy --all-targets -- -D warnings` clean.
- [ ] Commit trailers: `Implements: REQ-NNN` (new REQ for the extension surface) + `Refs: FEAT-NNN` (new FEAT if you want a feature trace) + `Refs: #546`.
- [ ] **Explicitly out of scope (file separately):** LSP-based hover / go-to-definition across artifact ids (richer slice — separate issue, would unlock JetBrains / Helix / Neovim too); marketplace publication (own decision call); non-VSCode editors; dashboard webview reuse; direction 2 (split out as sibling issue per below).

Direction 2 (suggest filing as sibling) — in-page edit + add buttons in rivet serve. A new "edit affordance in serve" surface, distinct from a VSCode extension — same artifact YAML, different editing seat (the rendered HTML page, not the file in the editor). Suggested AC for when you file it:

## Acceptance Criteria — `rivet serve` inline edit (direction 2 — file as sibling of #546)
- [ ] `rivet serve`'s per-artifact page grows an "Edit" affordance: a form per schema-defined field (typed input for enums / refs / numbers / dates; YAML-text for free-text `description:`-shaped fields). Save writes the artifact YAML back to disk via a serve endpoint; the page refreshes the rendered view in-place.
- [ ] The per-folder / artifact-list side panel grows an "Add" button that opens a new-artifact form: type-selector → schema-driven fields → equivalent to `rivet add` under the hood. Lands the new artifact in the appropriate file/dir per the project's existing source-config conventions (single-file source: append; directory source: write `<id>.yaml`).
- [ ] Edits/adds run `rivet validate` server-side **before** write; validation errors are surfaced in-page (inline diagnostics on each invalid field) so the same diagnostics the CLI shows reach the user. Failed validation does not modify the file on disk.
- [ ] Concurrency: write-while-another-edit-is-open conflict is detected (mtime / sha check) and surfaces a "reload to see the latest" prompt rather than silently overwriting. Tested by editing the same artifact in two tabs.
- [ ] Bound to the existing serve bundle — no new tool surface, no separate process. Disabled in static export (already no JS runtime there, so the buttons just aren't rendered).
- [ ] AI provenance: each serve-side write goes through the same PostToolUse-style stamping path so the audit trail (REQ-104 / #104) doesn't get a blind spot from in-page edits. Recorded under `created-by: human` (or `ai-assisted` if invoked via an agent integration in a later iteration).
- [ ] Commit trailers: `Implements: REQ-NNN` (new REQ for serve-side edit affordance) + `Refs: FEAT-001` + `Refs: #546` (sibling).
- [ ] **Explicitly out of scope:** multi-user collaborative edit; undo/redo beyond what the form widget provides; rename / move (different operation shape, separate slice); direction 1 (the VSCode extension); auth model for who can edit (assumes local-only `rivet serve`; remote-serve auth is a separate design call).

Either or both can ship in parallel; they don't interact (different runtimes, different editing seats). Recommendation: take direction 2 to a sibling issue so this one stays a single-PR target.

Process side-rail: https://pulseengine.eu/blog/ is still HTTP 503 — same long-standing expired-TLS / site-infra symptom flagged across the last ~25+ triage threads. The binding workflow guidance can't be consulted, so no PR will land from this triage regardless. Comment is the AC split + sibling-issue suggestion only.

Not implemented this run.

---

Generated by Claude Code — issue-triage agent run 2026-06-22.

---

Generated by Claude Code

[avrabe]

Triage (scheduled run): the issue title says vsix and the body says "we miss the UI for helping humans" — that's a discussion prompt, not an actionable ticket. Holding for scoping.

Two distinct directions hide in here; please decide and add explicit AC for the one you want:

A. Extend the existing rivet VS Code extension (LSP-driven YAML editing helpers — completions, lenses, snippets, schema hover):

## Acceptance Criteria
- [ ] Add `rivet add` / `rivet next-id` quick actions accessible from the YAML buffer
- [ ] Inline link autocomplete: typing `verifies: ` shows valid artifact IDs of the allowed target types
- [ ] Hover on an artifact ID shows title + status + a link to open the file
- [ ] One Playwright/VSCode e2e test exercises one of the quick actions

B. Custom editor (webview) for artifact YAML (form-based, hides YAML from the human):

## Acceptance Criteria
- [ ] Right-click on an `artifacts/*.yaml` opens a form editor with one field per schema-declared field
- [ ] Save round-trips cleanly back to YAML (existing comments / formatting preserved — round-trip equivalence test required, mirrors REQ-028 discipline)
- [ ] Validation diagnostics show inline on the form

(A) is much cheaper and reuses the LSP; (B) is the "user complained YAML is cumbersome" answer. Pick or split. Also please link the existing VSCode extension repo + version if there is one.

— rivet triage (Claude Code, scheduled)

---

Generated by Claude Code