[db-tycoon-stephen]

What this does

tycoon data status said "last build never" for every staging, intermediate and marts panel, even when tycoon data history listed the builds. Status now matches nodes by their dbt unique_id and reads build times in the right time zone.

Mental model

• Input: the manifest's models per layer, and the dbt_runs / dbt_nodes rows written by capture_dbt.
• Change: status looked nodes up by bare model name (stg_orders), but dbt_nodes.node_name has always held the unique_id (model.<project>.<name>). It now passes the unique_id. Fixing that exposed a second problem: started_at is stored as local wall-clock time in a naive TIMESTAMP, and the freshness label read it as UTC. The query now casts to TIMESTAMPTZ in the same DuckDB session time zone, which recovers the real instant.
• Outcome: each layer shows the age of its most recent successful build ("2h ago"), matching data history. Before, it was always "never". With only the name fix, a build 2h old would have shown as "6h ago" in New York.

dbt_runs.success being NULL (#341) is not the cause; this query never reads it. #341 stays open for data history.

Linked issue

Closes #390

Type of change

• Bug fix
• New feature
• Docs
• Refactor / internal
• Other:

Checklist

• pre-commit run --all-files passes
• Tests pass locally, and the offline csv-import pipeline still runs end to end (this is the CI gate — if it breaks, the release is blocked)
• Added or updated tests where it made sense
• Updated CHANGELOG.md if this is user-facing
• Updated docs / README if behavior or commands changed

Notes for reviewers

• Upgrade safety: ledgers written by 0.2.2 and earlier need no migration. They already store unique_ids, their NULL success is never read, and their local-time started_at is what the cast expects. A test captures a real dbt-shaped run_results.json to cover this.
• The time zone test runs in a subprocess per zone (UTC, America/New_York, Asia/Tokyo), because DuckDB fixes its session time zone when the process starts.
• Known limit: if the machine's time zone changes between a build and data status, the age is off by the difference. Storing UTC at capture time would fix that, but it's a writer change and is left out here.

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[github-actions]

PR size check

mode: warn | file limit: 8

Files changed: 3 counted / 8 allowed

• CHANGELOG.md
• src/tycoon/commands/status.py
• tests/test_status_last_build.py

Result: ✅ within limits.

[github-actions]

PR title check

mode: warn

fix(gh-390): show each dbt layer's last build in data status

Result: ✅ title matches the convention.

[Mercy2codesgit]

@db-tycoon-stephen Thanks for the fix. While reviewing this area, I had a follow-up thought from both a user experience and data reliability perspective.

Could we consider extending tycoon data status to show the outcome of the latest dbt build attempt alongside the last successful build time?

For example, if the latest build fails but the previous successful build was two hours ago, the status could make both facts visible.

From a business perspective, this could help users identify potentially stale data without having to inspect run history separately. For analytics and attribution workflows, where decisions depend on complete and up-to-date data, knowing that a recent build failed helps users assess whether the available output can still be trusted.

Would this be a useful enhancement to consider for the backlog, perhaps as a separate issue from this PR?

[db-tycoon-stephen]

Agreed that showing the latest attempt alongside the last success belongs in data status. It is out of scope here, and the ledger cannot answer it yet: failed runs never reach dbt_runs (#377) and dbt_runs.success is always NULL (#341). Both are in v0.2.4.

I opened #433 for the enhancement, blocked on those two. Could you add anything to it that you would want from the status line, such as whether the failed attempt's error summary should show inline?

[Mercy2codesgit]

Thank you for the work on this PR.

I reviewed the implementation and its regression coverage. The changes correctly address the model identification issue by matching dbt nodes using their unique_id rather than their bare model names. The timestamp handling also addresses the timezone discrepancy when calculating build freshness.

I particularly appreciate the tests covering:

• Successful builds across staging, intermediate, and marts layers.
• Layers with no recorded builds.
• Compatibility with existing ledger records where dbt_runs.success is NULL.
• Consistent build-age reporting across different timezones.

I ran the new regression tests and the related existing test suites locally. All 55 tests passed.

The implementation looks good to me, and I haven't identified any blocking code issues.

One outstanding item: The CHANGELOG.md merge conflict should be resolved before merging.

Overall, good work on this fix. Thanks!