feat: Describe modal for Project Status

[royendo]

Adds a resource describe modal to the Project Status resources table. Clicking the "View spec" action on any resource opens a dialog with structured, human-readable details about that resource.

https://www.loom.com/share/f0de3b4aec6b47a5886720f9e6d5dd8f

Supported resource types:

• Connector — driver, environment variables, properties, provision args
• Source / Model — general info (input/output, change mode, refresh, materialize, incremental, partitioned), SQL in code format, properties, stage, runtime stats, retry config, tests
• Metrics View — data source, time config, dimensions, measures, caching, AI instructions, security policy, annotations
• Explore — general settings, dimensions/measures selection, security policy
• Canvas — general settings, layout, clickable components (drills into component detail with back navigation), variables, pinned filters, security policy
• Component — renderer, renderer properties, input/output variables
• Theme — color swatches (primary/secondary), light/dark mode overrides
• Alert / Report — navigates to existing /-/alerts/{name} and /-/reports/{name} detail pages

Checklist:

• Covered by tests
• Ran it and it works as intended
• Reviewed the diff before requesting a review
• Checked for unhandled edge cases
• Linked the issues it closes
• Checked if the docs need to be updated. If so, create a separate Linear DOCS issue
• Intend to cherry-pick into the release branch
• I'm proud of this work!

---

Developed in collaboration with Claude Code

[ericpgreen2]

This is a nice upgrade from the raw JSON dump, and the per-type structured views are thoughtfully done. But before we invest in polishing individual components, I want to raise a concern about the overall approach.

This PR adds 14 files and ~1,200 lines of bespoke per-type UI. Each resource type gets a hand-crafted Svelte component that renders specific fields from the proto definition. The maintenance concern is: when someone adds a field to V1MetricsView, V1Model, or any other resource type, they'll need to remember to update the corresponding *Describe.svelte component. In practice, they won't. This surface will silently drift out of sync with the actual resource specs, and there's no automated way to catch it.

The audience for this feature is data engineers and Rill support staff on the Project Status page. They're debugging resource configuration and runtime state. They can read structured data.

Some alternative approaches that would reduce maintenance burden:

1. Show the YAML source file. Every resource has meta.filePaths. Render the actual source file with syntax highlighting, plus a small section for runtime state fields (refreshedOn, rowCount, etc.) that aren't in the YAML. Zero per-type maintenance, always in sync with the source of truth. The trade-off is less "human-readable" formatting (no friendly labels, color swatches), but for this audience that's probably fine.

2. Improved generic renderer. Instead of 10 bespoke components, build one good structured JSON/YAML viewer with collapsible sections, syntax highlighting, and a few type-aware formatters (dates, byte sizes, colors). Covers all resource types, including future ones, with no per-type code.

3. Data-driven mapping. Replace per-type components with per-type mapping functions that produce a flat list of {section, label, value} tuples. One generic component renders the list. The mapping functions are pure data transforms, easier to test and maintain than full Svelte components, and the rendering logic is shared.

I'd lean toward option 1 for its radical simplicity, but any of these would significantly reduce the long-term maintenance surface.

---

Developed in collaboration with Claude Code

[royendo]

▎ I've reworked this to use a generic structured renderer (your option 3). One mapResource() function recursively walks any resource's .spec and .state objects and produces {section, label, value} tuples. A single StructuredView.svelte component renders them. New proto fields appear automatically with no code changes.

▎ For option 1 (showing the YAML source file): the runtime's GetFile API requires ReadRepo permission, which cloud JWTs don't grant. There's no admin-side API that proxies file reads from the deployment's git repo either — GetVirtualFile only covers UI-created files, not GitHub-sourced project files. So source file viewing isn't feasible on cloud today without a backend change.

I've left it out for now but it would be a nice follow-up if we add a cloud-compatible file read API.

[royendo]

Code review fixes pushed

Implemented

1. Bug: Off-by-one in firstMonthOfYear — Proto uses 1-indexed months but MONTH_NAMES is 0-indexed. Fixed with MONTH_NAMES[idx - 1].

2. Svelte 5 migration of ResourceSpecDialog.svelte (new file) — export let → $props(), $: → $derived, createEventDispatcher → callback props (onback, onviewcomponent), on:click → onclick, <svelte:component> → {@const Icon}, added aria-label on back button.

3. Svelte 5 migration of StructuredView.svelte (new file) — export let → $props(), $: → $derived/$effect/$state, reactive function → plain function.

4. on:view-component / on:back → callback props in ProjectResourcesTable.svelte consumer.

5. Dead LABEL_MAP entries removed — 6 keys that duplicated SKIP_KEYS were never reached.

6. FLAT_ARRAY_KEYS comment added — Explains scaffolding intent for the empty set.

7. Variable shadowing fixed — obj renamed to record inside flatten() to avoid shadowing the parameter.

8. border-border-muted → border — Nonexistent design token replaced with the default border token (2 occurrences).

9. Consistent item spacing — Grouped items now match ungrouped: w-36/gap-x-4/min-h-[20px].

10. {#each} keys added — All 4 loops keyed: sections by name, groups by group, items by label.

11. Accessibility — aria-hidden="true" on decorative SVG chevron, aria-label on back button.

Not fixing

• No tests for resource-mappers.ts — 572 lines of pure transformation logic. Good candidate for a follow-up PR with unit tests for mapResource, formatValue, cleanEnum, prettyLabel.
• No loading state for canvas component fetch — Minor UX concern; fetchComponentResources is fast for typical canvas sizes.

---

Developed in collaboration with Claude Code