Skip to content

seven UX papercuts from dogfood run 3: img2img says "Workflow: txt2img" on the approval screen, no --limit on app status, doubled ✓ glyph, and four docs nits #365

Description

@ZacxDev

Re-verified today against civitai v0.1.92-10-g3156b80 (built from main @ 3156b80).

Small, individually-cheap fixes. Each was re-run or re-read against current main; two
sub-items from the original report did not survive and are recorded as refuted at the
bottom rather than filed.


1. An img2img job says Workflow: txt2img on the screen you approve

$ civitai generate "a cat" --image ./probe.png --ecosystem Flux1Kontext --dry-run
  Ecosystem:  Flux1Kontext
  Image:      ./probe.png (512x512) → https://orchestration-new.civitai.com/v2/consumer/blobs/…
If this ecosystem does not support image editing, the server IGNORES the images above,
generates from the prompt alone and still charges — the estimate cannot show the difference.
…
Workflow:         txt2img
Prompt:           <not checked by --dry-run>
Resources ready:  true

Estimated cost
  …
  total       45
rc=0

Workflow: txt2img is correct — the server promotes the job to image-to-image from the
presence of --image plus --ecosystem, and AGENTS.md item 19(a) records exactly that. But
this is the confirmation summary a user reads before approving a spend, on the same screen as
a warning that says the server may "IGNORE the images above". Reading txt2img there is the
single most alarming thing on the screen, and nothing explains it.

Fix: annotate it — Workflow: txt2img (the server promotes this to image-to-image because --image and --ecosystem are set) — or show the promoted name. Do not silently rename the
field; the wire value is txt2img and item 19(a) depends on that staying visible.


2. app status has no --limit, its sibling app list does

$ civitai app status
note: showing the newest 100 submissions — the API caps this listing and offers no way to page,
so older submissions may exist but are not listed. Look up a specific app with
`civitai app status <blockId>`.
BLOCK_ID                    VERSION  STATUS     DEPLOY        SUBMITTED   URL
… 100 rows …

Flags: --id, --json, --help. app list has --limit and --cursor.

The note (added by #207) is honest about why there is no --cursor — the API cannot page.
That does not explain the absence of a client-side --limit, which is the useful half: the
common interactive question is "what are my last five submissions", and today the answer is
| head.

Fix: a display-side --limit N on app status. Keep the cap note.


3. ✓ Icon set ✓ — the glyph is printed twice

internal/cmd/app_listing.go:546:

fmt.Fprintln(out, ui.Success(fmt.Sprintf("%s set ✓", capitalize(string(kind)))))

ui.Styler.Success already prefixes "✓ " (internal/ui/ui.go:265), so the rendered line is
✓ Icon set ✓. Same at app_listing.go:675 (✓ Screenshot removed ✓) and :711
(✓ Reordered 3 screenshots ✓). Drop the trailing glyph from the three format strings.


4. "square-ish, not exactly square" reads as prohibiting 1:1

README.md:1273:

| icon | 0.9 – 1.1 — square-ish, not exactly square | 128 px on the shorter side |

while README.md:249 recommends starting from 512 × 512 — which is exactly square. The
bound is 0.9 ≤ aspect ≤ 1.1, so 1:1 is the centre of the accepted range; "not exactly
square" is meant to say "it need not be exactly square" and reads as "it must not be".

Fix: 0.9 – 1.1 — square or near-square (1:1 is fine).


5. The README sends a released-tarball user to AGENTS.md six times

README.md lines 1017, 1311, 1792, 2301, 2314, 2333 all link to
AGENTS.md — including 1792, which is where a generate user is sent to learn
the per-ecosystem image-editing table (items 13 and 19(c)). AGENTS.md is a contributor file
and is not in the npm package or the Homebrew cask; a user who installed the CLI has no copy,
and the relative link 404s outside the GitHub web UI.

Fix: for the user-facing ones (1311, 1792 especially) either inline the fact or link the
absolute GitHub URL. Per CLAUDE.md, README.md is the published user contract — it should
not route the contract through a contributor doc.


6. dev:harness / dev:tunnel pin port 5186 with no override

internal/scaffold/templates/page-money/vite.config.ts.tmpl:55-56:

    host: 'localhost',
    port: 5186,
    strictPort: true,

strictPort: true means a second scaffolded app, or anything else on 5186, fails the dev
server outright rather than picking another port — and there is no env knob, because the port
also has to match VITE_BLOCK_ALLOWED_PARENT_ORIGINS=http://localhost:5186 in
env.development.tmpl:7. The run measured the collision surfacing as a raw Vite stack trace.

The pin itself is deliberate and correct (the origin must be stable for the SDK's
IframeTransport). What is missing is a knob that moves both values together, and a
readable message when the port is taken.


7. .env.production is bundled and nothing says so

internal/pkgzip/pkgzip.go excludes .env, .env.local, .env.*.local and
.env.development (lines 81-86) and explicitly keeps .env.production (line 102).

README.md:499 documents the exclusion:

.env.development* is never committed (submit excludes it) and the token is …

Nothing anywhere documents that .env.production is shipped to the platform in the
submitted bundle. The reasoning in the source comment is sound (the server build runs
vite build in production mode and reads it; it holds only public VITE_ values) — it just
needs to be in the README, because "the CLI excludes dotenv files" is the natural inference
from the sentence that is there.


Refuted on re-verification — not filed

  • "app view truncates mid-word without an ellipsis." It appends one:
    internal/cmd/collections.go:248 returns s[:max] + "…". (There is a latent, separate
    nit — s[:max] slices bytes, so a truncation landing inside a multi-byte rune emits a
    broken one. Worth a line if anyone touches this, but it is not the reported defect.)
  • "the BLOCK_READY advisory is ~200 words as the first warning a newcomer sees." The word
    count is right (~190), but a fresh scaffold no longer triggers it — I had to strip
    BLOCK_READY out of civitai-host.js, index.html and app.js of a --template static
    scaffold by hand to make it fire. It reaches only authors of apps scaffolded before Scaffolded 'static' (default) and 'page-vite' apps never send BLOCK_READY — the host times out and collapses them #206, who
    are the audience it is written for. Leaving it alone.

Source: blind credentialed dogfood run 3, 2026-08-10 (claudedocs/handoff-dogfood-3.md,
findings 10, 13, 14) — an agent given the built binary and a live token, forbidden from reading
the CLI source, AGENTS.md or the prior run reports. Every item above was re-run or re-read
against current main before filing. The generate command in item 1 was run with --dry-run
only — nothing was submitted or charged.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions