3 Commits

Author SHA1 Message Date
f6ac20c8ed TASK-063: task records say what is actually open
No task waits on a Codex review; the redesign tasks are confirmed on the
product owner's Z Fold7; TASK-016's leftovers are on hold; no biometric
reauthentication.

Agent: main (opus)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-29 20:25:49 +09:00
18e59d960c TASK-036 follow-up: deep-link the favorite-push notification
Tapping the notification now opens the app directly at that
repository's file browser on its default branch, instead of just the
app's normal entry point. The push-detection step only tracks one
scalar 'latest push time' per repository, not which branch produced
it, so the deep link targets the repository's default branch rather
than the specific pushed branch -- still a correct, useful 'take me to
this repository' action.

ListFavoritedRepositoriesUseCase now returns full RepositorySummary
(not just coordinates) so defaultBranch is available; MainActivity
bridges the notification's PendingIntent extras into its existing
Route/routeStack navigation via a mutableStateOf Activity property read
by a LaunchedEffect, mirroring the existing OAuth-callback consumption
pattern.

Live-verified via a simulated notification-tap intent (adb shell am
start with the exact extras FavoritePushNotifier sets): opened directly
at the target repository's file browser on the requested branch,
screenshot-confirmed, no crash.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-29 17:26:23 +09:00
b1a00233b0 TASK-036: push notification when a favorited repository gets a new push
Gitea's own notification feed doesn't fire for plain pushes (only
issue/PR activity), so this app now periodically checks each favorited
repository's most recent push time itself and posts a local
notification when it advances past what was last seen.

- FavoritePushDetector: pure comparison logic, never notifies on a
  repository's first sighting (only a real advance counts), avoiding a
  notification storm the first time this feature ever runs.
- GetLatestPushEpochMillisUseCase: extracts the same 'newest branch
  commit time' heuristic RepositoryListViewModel already uses for the
  repository list's own last-push row, as a shared, reusable use case.
- SharedPreferencesLastSeenPushStore: one long per favorited repo, not
  Room (docs/architecture.md reserves Room for offline caching).
- FavoritePushCheckWorker: 15-minute WorkManager periodic job,
  network-constrained, no-ops cleanly with no session or no favorites.
- POST_NOTIFICATIONS requested at runtime on API 33+; a denial
  degrades safely, the worker still runs and updates its baseline.

No deep link from the notification to the specific repository yet --
tapping it opens the app normally. End-to-end delivery (a real push
landing, 15 minutes elapsing) is unit-tested and the scheduling/
permission wiring is live-confirmed (prompt appeared, was granted, no
crash), but an actual notification firing hasn't been observed within
this same live-testing session.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-29 17:15:35 +09:00