Lists: `CreateListAsync` sends 2 of the 11 fields `POST /api/lists` accepts — `initialRows` would remove an N+1

[Adron]

The gap

POST /api/lists accepts eleven fields. CreateListAsync sends two (title, isPublic):

public async Task CreateListAsync(string title, bool isPublic, …)
    => … new { title, isPublic } …

Found by #73's probing (PR #175), which needed source + githubRepo and discovered the rest.

The spec's request properties include title, description, isPublic, parentId, folderId, schema, source, githubRepo, githubSource, initialRows, messageId.

Why initialRows in particular matters

Three features currently create a list and then add rows one at a time:

• Powered Templates (AI: Powered Templates — generate a list from a description #174) — an AI powered_template artifact returns a full dsl and rows; today that's 1 create + N row POSTs.
• Materialize (Materialize ("Create from…") service layer + models #136) — listConfig.includeData seeds rows from a source, so the server already does this server-side; but a client building a list from data hits the same N+1.
• Any import path.

initialRows collapses that to one request. With no transaction across N+1 requests, a partial failure today leaves a list with some of its rows and no clean way to report that.

The other fields already have consumers waiting

Field	Wanted by
description	#18 (schema builder already collects one)
parentId	#64 parent/child hierarchy + breadcrumbs
folderId	#63 list folders
schema	#17/#18 — already used via a separate overload on PR #143
source + githubRepo	#73 GitHub-backed lists — used on PR #175
messageId	provenance when a list is created from a message (Materialize)

So this isn't speculative: most of these are being added piecemeal by whichever issue needs them. Consolidating CreateListAsync into one options object would stop that.

Verified behaviour worth keeping

• source: "github" without githubRepo → 400 "githubRepo is required for GitHub-backed lists (format: owner/repo)", and creates nothing (verified — no orphan list).
• Create returns {message, data:{…}}, not {list:{…}}.

Acceptance criteria

• CreateListAsync takes an options object covering the accepted fields rather than growing positional parameters
• initialRows supported, and the callers above collapsed from N+1 to one request
• initialRows response shape verified live on a throwaway list before being typed strictly
• Existing two-argument callers keep working (overload or optional parameters)

Note

Filed from a review finding, not the parity audit. Low urgency — the current path works, it's just chatty and is being extended one field at a time by four different issues.

[Adron]

Two corrections to my own issue text above, from checking the source rather than trusting the report:

1. CreateListAsync sends {title, description}, not {title, isPublic}.

// InterlinedApiClient.Lists.cs:24
public async Task<ListSummary> CreateListAsync(string title, string? description, …)
    => … new { title, description } …

So isPublic is among the missing fields, which makes the gap slightly worse than I wrote: a list created from this app cannot be made public at creation time.

2. The accepted field list is exactly:

title, description, messageId, metadata, schema, parentId,
isPublic, source, githubRepo, githubSource, initialRows

So folderId is not among them — I listed it, wrongly. There's metadata instead, which I'd omitted. That means #63 (list folders) cannot set a folder at creation time either; a newly created list would have to be moved into its folder with a follow-up call, or via PUT /api/lists/{id}. Worth checking which, when #63 is built.

Corrected table:

Field	Wanted by
isPublic	any create — currently unreachable from this app
parentId	#64 hierarchy + breadcrumbs
schema	#17/#18 — already used via a separate overload on #143
source + githubRepo + githubSource	#73 — used on #175
messageId	Materialize provenance
metadata	opaque; unverified
initialRows	#174, #136 — removes the N+1