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
- A
@swamp/software-factorymodel with one or more started work items. - Run the factory-wide status (no workItem):
swamp model method run <factory> status - 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
Closed
No activity in this phase yet.
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 recordedWhat 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.