Create all type: model files in models/ instead of sources/

[lovincyrus]

This PR creates all type: model files in models/ instead of sources/

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!

[royendo]

barring fail e2e, looks good to me

[ericpgreen2]

isSourceModel heuristic can false-positive on YAML-only models

In file-and-resource-watcher.ts:368-369, the source detection changed from filePaths[0]?.startsWith("/sources/") to:

const isSourceModel =
  filePath?.startsWith("/models/") && filePath?.endsWith(".yaml");

This matches any YAML file in /models/, but not all of those are sources. A model defined entirely in YAML (like the incremental model in the test suite) would also match. Combined with the other conditions in isNewSource — specVersion === "1", stateVersion === "2", and isLeafResource — a YAML-only leaf model would incorrectly trigger the "Source imported successfully" modal on first reconciliation.

The runtime already tags sources with defined_as_source: true in parse_source.go:35. If that flag is available on the model spec in the frontend, checking it here would be more precise than relying on the file extension.

---

Developed in collaboration with Claude Code

[lovincyrus]

Question: How should the watcher detect newly-imported sources?

The e2e test breadcrumbs.spec.ts is failing because the "Source imported successfully" modal never appears after a file upload. Here's why:

Background

The FileAndResourceWatcher shows the modal by setting sourceImportedPath when it detects a new source has finished ingesting. Previously it used a path-based check:

const isSourceModel = res.resource.meta?.filePaths?.[0]?.startsWith("/sources/");

Since this branch moves source files to models/, that check was replaced with:

res.resource.model?.spec?.definedAsSource === true

The problem

The YAML generated by sourceModelFileTop() uses type: model (intentionally — that's the goal of this branch). But definedAsSource is only set automatically by the Go parser when it processes type: source files (via parseSource). For type: model files, it reads defined_as_source from the YAML itself — and it's not there.

So definedAsSource is always false for UI-created sources, and the modal never shows.

Options

1. Add defined_as_source: true to the generated YAML — it's a valid field in the model YAML schema (parse_model.go line 48). The generated YAML would be:

   type: model
   materialize: true
   defined_as_source: true

2. Use type: source in generated YAML — the parser converts it to a model internally and sets defined_as_source: true automatically. But this goes against the branch goal of creating type: model files.

3. Use a different watcher heuristic — e.g. check materialize + isLeafResource instead of definedAsSource. But this is fragile and could false-positive on regular materialized models.

Thoughts on which approach is best? @ericpgreen2

---

Update: resolved offline.

resolved

[ericpgreen2]

The path migration from /sources/ to /models/ looks complete — no stale references remain. The pendingSourceImports approach is a better signal than the old startsWith("/sources/") heuristic. Two things worth addressing:

---

1. Missing cleanup in createSource.ts

createSource adds to pendingSourceImports before calling runtimeServicePutFile but never cleans up on failure. If the PUT throws, the entry leaks in the Set. Compare with submitAddDataForm.ts which correctly cleans up in both error paths.

The callers (FileDrop.svelte, LocalSourceUpload.svelte) catch errors but don't clean up either.

---

2. pendingSourceImports and sourceImportedPath are implicitly coupled

This PR introduces pendingSourceImports as new state that's tightly coupled to the existing sourceImportedPath — the watcher has to remember to call delete on one and set on the other in lockstep, and error paths have to delete without setting. That coupling is invisible and easy to get wrong (see issue 1).

Since you're introducing new state here anyway, consider synthesizing both into a single class that owns the full ingestion lifecycle:

class SourceIngestionTracker {
  private pending = new Set<string>();
  public ingestedPath = writable<string | null>(null);

  trackPending(filePath: string) {
    this.pending.add(filePath);
  }

  isPending(filePath: string) {
    return this.pending.has(filePath);
  }

  /** Ingestion finished — remove from pending and notify the UI */
  trackIngested(filePath: string) {
    this.pending.delete(filePath);
    this.ingestedPath.set(filePath);
  }

  /** Source creation was rolled back */
  trackCancelled(filePath: string) {
    this.pending.delete(filePath);
  }

  /** User dismissed the success modal */
  dismiss() {
    this.ingestedPath.set(null);
  }
}

This makes the transitions explicit — trackIngested vs trackCancelled — so it's impossible to forget half the pair. The watcher calls tracker.trackIngested(filePath) instead of two separate operations, and error paths call tracker.trackCancelled(filePath) with clear intent.

The naming also aligns with the domain language the UI already uses ("has been ingested") and replaces the more ambiguous "imported" terminology.

resovled