Conversation
| const c = row.usageCoverage[field]; | ||
| const value = usageValue(row, field); | ||
| if (c.knownTurns === 0 && c.unknownTurns === 0 && c.missingTurns > 0) return '—'; | ||
| const suffix = c.knownTurns === row.turns && c.unknownTurns === 0 ? '' : '*'; |
There was a problem hiding this comment.
🟡 formatUsageCell asterisks every usage number for pre-#41 turns, creating a noisy display regression
For existing users whose ledger consists entirely of pre-#41 turns (no fidelity field), formatUsageCell marks every usage column with * and hasPartialDisplayCoverage triggers the footnote * partial coverage: some numeric fields or prices are unknown…. This happens because updateField at packages/cli/src/commands/summary.ts:417-419 increments unknownTurns for every turn without fidelity. Then the suffix condition at line 429 (c.knownTurns === row.turns && c.unknownTurns === 0) is always false when unknownTurns > 0, producing * on every cell.
This is inconsistent with the rest of the codebase's convention to treat unknown-fidelity turns as "best-effort full" — compare.ts:219-221 includes them, plan-usage.ts:163-164 costs them, waste.ts:159 skips them in fidelity checks. But burn summary penalizes them visually. The cost column is unaffected (since hasCostCoverage returns true for them), making the inconsistency jarring: clean cost but asterisked usage numbers.
Prompt for agents
In formatUsageCell (packages/cli/src/commands/summary.ts:425-431), the suffix condition on line 429 treats unknownTurns the same as missingTurns, but everywhere else in the codebase turns without fidelity are treated as best-effort full. The fix should count unknownTurns alongside knownTurns for the clean-display condition, e.g. by changing the suffix condition to only show asterisk when missingTurns > 0. Similarly, hasPartialDisplayCoverage at line 454-458 should not flag unknownTurns as partial. This ensures pre-#41 users don't see noisy asterisks on every field while still flagging fields that are explicitly declared as missing.
Was this helpful? React with 👍 or 👎 to provide feedback.
|
Recommending close in favor of the granular issue-by-issue PRs (#115, #116, #132, #133, #134, #135), which together cover everything in this PR's scope except the That piece is now tracked separately as #136 so it doesn't get lost. Note on JSON contracts: the granular PRs (#134 plans, #135 compare) use the shared Granular coverage map:
|
Summary
Closes #41
Tests