Skip to main content
← Back to list
01Issue
BugClosedExtensions
AssigneesNone

Relationships

#1043 work-item-summary report renders zero rows despite work items existing

Opened by vcjdeboer · 7/8/2026

Description

The @swamp/software-factory/work-item-summary report — rendered by the factory-wide status method (called WITHOUT a workItem) — prints its header and horizontal rules but zero rows, even when the factory has many work items.

Steps to reproduce

  1. A @swamp/software-factory model with one or more started work items.
  2. Run the factory-wide status (no workItem): swamp model method run <factory> status
  3. Observe the report region:
── Report: @swamp/software-factory/work-item-summary ──
<one blank line>
──────────────────────────────────────────────────────

Expected vs actual

  • Expected: one summary row per work item (stage / status / cycles / …).
  • Actual: zero rows. In my repo the factory has 8 work items (capture-full, capture-inputs, capture-messages, external-data, inspect, lock-env, provenance-graph, vault-creds — 83 data records), yet the summary is blank. Workaround: query each item individually via status --input workItem=<ref>.

Environment

swamp 20260708.202130.0-sha.3afd02a8; macOS arm64 (darwin 25.2.0)

Suggested fix

The all-work-items overview appears not to resolve/emit its rows — verify it enumerates the work-item set the same way per-item status does.

Upstream repository: https://github.com/swamp-club/swamp-extensions

Environment

  • Extension: @swamp/software-factory@2026.06.16.1
  • swamp: 20260708.202130.0-sha.3afd02a8
  • OS: darwin (aarch64)
  • Deno: 2.8.3
  • Shell: /bin/zsh
02Bog Flow
OPENTRIAGEDIN PROGRESSCLOSED

Closed

7/28/2026, 1:59:51 PM

No activity in this phase yet.

03Sludge Pulse
Editable. Press Enter to edit.

vcjdeboer commented 7/28/2026, 1:59:50 PM

Update from the reporter, with a correction — and the original need is resolved.

The overview now exists. On @swamp/software-factory@2026.06.24.1, a factory-wide status (no workItem) persists a status-_factory resource with one row per run — workItem, stageId, status, cycle, startedAt — which is exactly what this issue's "Expected" section asked for. Verified on a probe factory with three work items. The run output also points at it directly (→ swamp data get <factory> status-_factory).

I filed this against 2026.06.16.1, where that record did not exist: the same code path computed the run list but emitted it only as a STATUS_JSON {…} log line, with nothing persisted and nothing queryable. So the gap I hit is closed, and the per-item status --input workItem=<ref> workaround I described is no longer needed. Thank you.

My diagnosis was wrong, though, and I'd rather correct it than leave it sitting here. I suggested the report "appears not to resolve/emit its rows — verify it enumerates the work-item set the same way per-item status does." That points at the wrong code. reports/work_item_summary_report.ts returns early unless methodName === "summary" and a non-empty workItem argument is present. It is a per-work-item history by design, not a fleet table, and it renders correctly when invoked that way:

$ swamp model method run <factory> summary --input workItem=ITEM-1
── Report: @swamp/software-factory/work-item-summary ──
# Work Item: ITEM-1
Currently: active at build (cycle 1)
1 events · 1 stage visits · 0 artifacts recorded

What I actually saw is a swamp-side issue, not an extension one. A report that returns empty markdown still gets a rendered frame and a persisted 0-byte version, and that version becomes latest — so the blank region I reported here appears for every method the report doesn't handle. It reproduces identically on 2026.06.16.1 and 2026.06.24.1, so nothing the extension changed caused or fixed it. Filed separately as #1443.

Nothing left in this issue that belongs to the extension — closing as resolved by 2026.06.24.1.

Environment for the checks above: swamp 20260728.002907.0-sha.a809c490, macOS 15 (darwin-aarch64).

Sign in to post a ripple.