feat(cli): name which capture is awaiting a timestamp in status - #154
Merged
Conversation
`habitable status` already reported an aggregate "N awaiting" count of captures still queued offline for a timestamp token, but a tenant with intermittent connectivity had no way to tell *which* capture that was without inspecting the vault directly. Each issue's listing now names any of its captures still queued offline, by capture id, reusing the same `capture_awaiting` message the `capture` command already prints — so the next `habitable resolve` has a concrete target instead of a bare count. No new i18n strings: the EN/ES `capture_awaiting` message already covers this exact state. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RwvFhZbxJZZn4bpejFu3Vj
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
habitable statusalready reported an aggregatetimestamps: N/total present; M awaitingcount, but a tenant capturing evidence with intermittent connectivity had no way to tell which capture that was without inspecting the vault directly.statusnow names any of its captures still queued offline, by capture id, so the nexthabitable resolvehas a concrete target instead of a bare count.capture_awaitingmessage thecapturecommand already prints for the same state, so the mechanical i18n parity gate needs no new translation.Test plan
uv run ruff check/ruff format --checkon changed filesuv run mypy --strict src/habitable/cli.pytest_cli_status_lists_awaiting_captures_by_issue(captures a queued item and a timestamped item, asserts only the queued one appears instatus, and that the line disappears afterhabitable resolve)make verifygate green: 1015 passed, 90% overall coverage / 95% on the crypto-critical subset, i18n UTF-8/BCP47/parity gates, doc-links, and marker checks all pass🤖 Generated with Claude Code
https://claude.ai/code/session_01RwvFhZbxJZZn4bpejFu3Vj