Add Report

2b. A log format no reader knows → one reader in DataSources

A reader named for the format (JSONLinesReader, never AcmeLogReader) in Modules/DataSources/Sources/Internal/Logs/, test-first in Modules/DataSources/Tests/Logs/ with neutral fixtures, yielding the one LogRecord every reader yields. Then the JSON uses it. Add its row to ENGINE_DESIGN §1. Only scan files changed within the range (LogFileFinder).

2c. A different question → a capability

Design it in the docs first (CANONICAL §2.1, TARGET_ARCHITECTURE): declared in the definition, its own types in Modules/Providers, an @Observable handle on Account that is nil when not declared — like usageHistory and guestPasses. ProviderFactory.make builds it from the definition; a runner that lives outside the modules (a CLI the App runs, the Keychain) is supplied by the Engine the App builds once. The App never passes anything per provider.

Phase 3: The card, read on popover open

3a. The card view

Location: Sources/App/Views/{Name}CardView.swift. Match the existing cards; DailyUsageCardView is the reference:

struct {Name}CardView: View {
    let metric: {Name}Metric   // one case per card
    let report: {Name}Report
    let delay: Double          // cascading entrance

    @Environment(\.appTheme) private var theme

    var body: some View {
        VStack(alignment: .leading, spacing: 6) {
            // header: icon + LABEL · the large value · the progress bar · the delta line
        }
        .padding(12)
        .background(/* theme.cardGradient fill + theme.glassBorder stroke */)
    }
}

Card styling checklist: .padding(12) · theme.cardGradient + theme.glassBorder (1pt) · theme.cardCornerRadius · theme.fontDesign on text · theme.textPrimary/Secondary/Tertiary · theme.progressTrack · hover scale 1.015 · progress bar animated with delay.

3b. Read the days when the popover opens

Usage history is read when the popover opens, never in the background (#204), and per login — the page asks the selected login, as MenuContentView does:

.task(id: login.id) {
    guard let history = login.usageHistory else { return }   // nil: this login offers none
    let days = await history.days(in: .last(14))
    report = {Name}Report(days: days, splitAt: weekStart)
}

The view renders report; it never compares, counts or decides from the days itself.

3c. Nothing to register

ProviderFactory.make builds usageHistory from the definition, and every provider is found by ProviderCatalog.detect() (TARGET_ARCHITECTURE §10). The App passes nothing per provider.

Phase 4: Verify

1. tuist generate
2. xcodebuild test -workspace ClaudeBar.xcworkspace -scheme ClaudeBar-Workspace -destination 'platform=macOS,arch=arm64' — the full run; tuist test skips cached targets
3. Run the real popover on mock data (scripts/demo-screenshots.sh) — screenshots, never real names, emails or usage
4. Docs in the same change: the feature's README.md / design.md, one CHANGELOG line (≤300 chars), python3 scripts/gen-docs.py && python3 scripts/check-docs.py --strict

Checklist

Phase 0

• Placed: report over days · definition usageHistory · new reader · capability
• Design in the docs, diagram, pieces table, mockup in design-concept/<feature>/
• User approved

Phase 1

• {Name}ReportTests written first (deltas, nil percent, signs, progress, empty)
• {Name}Report in Modules/Quotas, built from [DailyUsageStat] — green

Phase 2 (only if needed)

• usageHistory block + golden tests, or a format-named reader in DataSources + its ENGINE_DESIGN row, or a declared capability
• No UsageSnapshot field, no analyzer protocol, no vendor-named Swift

Phase 3

• {Name}CardView matching the card style
• Days read on popover open, per login; nothing passed in ClaudeBarApp

Phase 4

• Full xcodebuild test green
• Screenshots on mock data
• Docs and CHANGELOG line; docs check passes