Add ProcessCard base card for Workspace setup-progress

[lukemelia]

What

Adds ProcessCard (packages/base/process-card.gts), a base CardDef representing a long-running setup-progress job (indexing, import, a guided setup flow).

Why

A realm's index card surfaces setup-progress jobs on its Home tab by querying the realm for ProcessCard instances via a codeRef (codeRef(here, './process-card', 'ProcessCard')) rather than a static import. The field names here are therefore a contract that consumer reads, and the card must exist in the base realm for those jobs to resolve and render.

(Unrelated to the Wiki/process-card.json fixture in the software-factory realm, which is a documentation page that adopts Wiki and merely shares the filename.)

Fields (the contract)

listingName, stage, processStatus (StringField), progressDone/progressTotal (NumberField), startedAt (DateTimeField), and an optional linked setupSurvey. Plus computed cardTitle (falls back to "Setup process") and getters percentComplete / progressLabel / statusLabel, driving a shared isolated/embedded/fitted template. The bar is the shared themed ProgressBar from boxel-ui; its progressbar ARIA semantics (role="progressbar", aria-value*) are added to the shared component in #5586.

Tests

• packages/host/tests/integration/components/process-card-test.gts — 10 tests covering the getters (fraction, clamping, unknown-total, status default) and rendering (aria attributes, copy, fill width, fallbacks).
• packages/host/tests/helpers/base-realm.ts — exports ProcessCard from the base-realm test helper (mirrors the CardsGrid wiring) so tests exercise the real base card via the loader.

Test plan: runs green locally against a full dev stack — 10 passed, 0 failed. Clean under glint (ember-tsc --noEmit), ember-template-lint, and prettier.

🤖 Generated with Claude Code

[github-actions]

Preview deployments

• Host staging preview

• Host production preview

Host Test Results

    1 files      1 suites   2h 54m 0s ⏱️
3 610 tests 3 595 ✅ 15 💤 0 ❌
3 629 runs  3 614 ✅ 15 💤 0 ❌

Results for commit cdb4ba1.

Realm Server Test Results

    1 files      1 suites   13m 45s ⏱️
1 933 tests 1 933 ✅ 0 💤 0 ❌
2 012 runs  2 012 ✅ 0 💤 0 ❌

Results for commit cdb4ba1.

[burieberry]

There's a ProgressBar component that already has the theming in place that might be sufficient. I used it in software-factory/realm/overview.gts for software-factory setup progress.

[lukemelia]

[Claude Code 🤖] Thanks for the review — all applied in the latest two commits:

• ProgressBar — swapped the hand-rolled track+fill <div> for <ProgressBar @value={{@model.percentComplete}} @max={{100}} />. That also resolves the bar-color notes for free, since ProgressBar themes its track with --muted and fill with --primary internally. Dropped the now-unused barStyle getter.
• font shorthand — replaced every font: usage (.process-card__stage, __name, __footer) with separate font-weight / font-size (--boxel-font-size-*) / line-height (--boxel-line-height-*), leaving font-family to inherit.
• --muted-foreground — applied to the stage and footer text (was --boxel-450).
• 3xs — header gap is now --boxel-sp-3xs (was the deprecated --boxel-sp-xxxs).

The rendering tests now assert the shared progress bar renders ([data-test-boxel-progress-bar]); percentComplete's math is already covered by its own unit tests. Ran locally — 10/10 pass.

I also captured the two conventions that weren't yet written down — no font shorthand, and reach for an existing themed boxel-ui component before hand-rolling — in the gts-component-conventions skill, so the next card gets it right up front.

[habdelra]

[Claude Code 🤖] Reviewed with two lenses: (1) does a base card that exists purely as a contract for a not-yet-landed consumer hold up on its own, and (2) did the design-review swap to the shared ProgressBar land cleanly. I checked out the head branch and traced the fields, the template, the shared ProgressBar, the base CardDef.cardTitle it overrides, and the failing CI check.

Bottom line: no blocking issues. The card is small, well-tested, and idiomatic; the design-review feedback was correctly applied. The items worth acting on before merge are the stale accessibility claims and confirming the memory-baseline CI failure is the expected "new module, no baseline" case.

What lands right

• The ProgressBar swap is the correct response to the review thread — it's the shared themed component, and it resolves the --muted/--primary token notes for free because ProgressBar themes its own track/fill internally. The unused barStyle getter was correctly dropped.
• The getters are the right shape and are unit-tested directly rather than through the DOM: percentComplete clamps to 0–100 and returns 0 (not NaN) when the total is unknown or ≤ 0; progressLabel returns '' on unknown total; statusLabel defaults to 'running'. @max={{100}} against a value already normalized to a percentage is correct (double-clamping in ProgressBar is harmless).
• Module wiring is sound: base modules resolve by path (@cardstack/base/process-card), so no manifest/registration entry is needed beyond the file itself; the base-realm.ts test-helper addition correctly mirrors the CardsGrid pattern.
• The gts-component-conventions skill additions (no font shorthand; reach for an existing themed boxel-ui component before hand-rolling; steer off the numbered palette toward semantic role tokens) are accurate and written evergreen.

On the earlier review thread
burieberry's ProgressBar suggestion is fully applied and the six styling threads are all addressed in the latest commits — nothing left open there.

Cross-cutting: the failing "Host Memory Baseline" check is this PR's new test module. The job log shows it failing with "2 module(s) exceeded hard memory threshold", and the two flagged modules are the two with no baseline row — one of which is Integration | Card | process-card at 5.9 MB (the other, an ai-assistant-panel module, isn't from this branch). A new host test module has no baseline entry, so it's measured against an absolute hard cap. 5.9 MB is not an obvious leak for a setupBaseRealm test (peers on the same run: read-source 5.7 MB, rendered-markdown 11.3 MB), so this reads as "new module, no baseline" rather than retention gone wrong — and the PR's mergeable_state is unstable, not blocked, so it's advisory rather than a required gate. Please confirm the intended flow: the Update Host Memory Baseline job was skipped on this PR (it runs on main), so the baseline should regenerate post-merge. If you want to be sure it's not genuine retention, a quick pass with the host-test-memory-leak lens on the two renderCard calls would settle it.

One thing this PR can't verify, by design. There is no consumer in the tree yet — no "System (n)" folding logic and nothing querying for ProcessCard — so the field-name spellings are the entire load-bearing surface and nothing pins them to what the forthcoming Workspace index card will read. That's acceptable for landing the card ahead of its consumer; just worth an integration test when the consumer lands that actually resolves ProcessCard via the codeRef and reads these fields, so a later rename of e.g. progressTotal fails loudly instead of silently.

Recommendations (all non-blocking; ordered by value)

1. Fix the stale accessibility claims — the PR body still says "an accessible role="progressbar" bar" and the rendering test is titled "…accessible attributes…", but the shared ProgressBar has no progressbar role/aria-value*; adding those to the shared component is a clean follow-up. See the thread on the <ProgressBar> line.
2. Confirm the memory-baseline flow above (advisory vs. required; baseline regenerates on merge).
3. Decide consciously whether cardTitle should drop cardInfo.name — consistent with Tag/Country/CardsGrid, differs from StyleReference. See the thread on the cardTitle field.
4. Consider making the progress unit ("items") customizable or noun-free, since the card spans indexing/import/setup-flow jobs. See the thread on progressLabel.
5. Give fitted a compact variant only if it clips in the smallest tiles. See the thread on the format assignments.

Adjacent, out of scope (minor, whoever touches this next)

• .process-card declares container-type: inline-size but there are no @container queries, so it's inert (it does establish a query container + inline-size containment, which is harmless here).
• data-status={{@model.statusLabel}} on the status span is keyed by nothing — no CSS or test reads it. Fine as a deliberate styling/testing hook, otherwise removable.
• startedAt and setupSurvey are unused in this card's own template — expected, since they're contract fields for the forthcoming consumer, not dead code.

---

Generated by Claude Code