Ubisam-MobileGit/docs/development-log.md

UBGitea development log

This is the append-only implementation and handoff record shared by Codex and Claude. Only the current task owner or assigned reviewer may append an entry, and agents never edit this file concurrently.

2026-08-25 — TASK-001

• Agent and role: Codex, implementer and integrator
• Commit/diff: 75aa5f8
• Features implemented: Android Compose project bootstrap, Korean placeholder home screen, deterministic Gradle wrapper, unit-test and lint baseline.
• How it was implemented: One application module using Kotlin, Compose, Material 3, API 28 minimum, API 36 target, JDK 17, and version-catalog-managed dependencies.
• Files changed: Root Gradle configuration, app/, ADR-001, product and task documentation.
• Checks and results: Debug APK build passed; 1 unit test passed; lint passed; sensitive-pattern scan found no assigned secret.
• Review findings and resolutions: Independent review found no P0-P3 findings.
• Known limitations: No device/emulator launch; final icon and authentication were out of scope.
• Next recommended task: Repository browsing foundations.
• Next owner: Codex.

2026-08-25 — TASK-003

• Agent and role: Codex, implementer and integrator
• Commit/diff: a2cc7d4
• Features implemented: Immutable repository, branch, tree, file, commit and paging domain contracts; safe coordinate/ref/path validation; read-only repository interface and browse use cases.
• How it was implemented: Pure Kotlin domain models, defensive byte/list copies, shared pagination validation, Korean read-only placeholder state, and fake-adapter unit tests.
• Files changed: Domain model/repository/use-case packages, focused tests, home placeholder, product roadmap and TASK-003 through TASK-007 documents.
• Checks and results: Build passed; 22 unit tests passed; lint passed; sensitive-pattern and diff checks passed.
• Review findings and resolutions: Two P2 findings covering page output mutability and missing use-case boundary tests were fixed and independently re-reviewed; no findings remain.
• Known limitations: Live HTTP, authentication, navigation, content rendering, and device testing were out of scope.
• Next recommended task: OAuth protocol core followed by Android OAuth integration.
• Next owner: Codex.

2026-08-25 — TASK-002A

• Agent and role: Codex, implementer and integrator
• Commit/diff: 6da016c
• Features implemented: OAuth client configuration, approved read-only scopes, fresh PKCE S256 verifier/state generation, authorization URL construction, exact redirect validation, transaction expiry, denial/success modeling, and strict callback query validation.
• How it was implemented: Pure Kotlin/JDK code with SecureRandom, SHA-256, unpadded Base64 URL encoding, RFC 7636 verifier grammar, deterministic query component encoding, constant-time state comparison, strict UTF-8 percent decoding, duplicate/ambiguous response rejection, saturating time boundaries, and redacted string representations for sensitive values.
• Files changed: core/auth/protocol/, matching protocol tests, ADR-002, TASK-002 umbrella, TASK-002A, and TASK-002B.
• Checks and results: Focused OAuth tests 21/21 passed; full unit tests 43/43 passed; debug APK build passed; Android lint passed; diff check passed; sensitive-pattern scan found no assigned secret/token/password/private key.
• Review findings and resolutions: P2 verifier grammar fixed with strict RFC character/length validation; P2 parameter pollution and malformed UTF-8 fixed with fail-closed parsing; P3 timestamp overflow fixed with saturating boundaries. Independent re-review found no remaining P0-P3 findings.
• Known limitations: System browser launch, App Link dispatch, code exchange, Keystore token vault, user identity, and real-server E2E are intentionally deferred to TASK-002B. E2E remains blocked by signing fingerprints and hosted assetlinks.json.
• Next recommended task: TASK-002B Android OAuth integration, completing locally testable browser/storage/exchange boundaries before the external E2E gate.
• Next owner: Codex.

2026-08-25 — TASK-011

• Agent and role: Codex, implementer and integrator
• Commit/diff: current TASK-011 working-tree diff; user-owned assetlinks.json excluded
• Features implemented: System-browser Gitea OAuth login, verified HTTPS App Link callback, PKCE code exchange without a client secret, Keystore-backed token storage and logout, authenticated identity check, and a paginated list of every repository visible to the account.
• How it was implemented: Exact callback validation reuses TASK-002A; pending verifier/state is consumed once; OkHttp runs asynchronously with cancellation/error propagation; Gson DTOs fail closed into typed API errors; /api/v1/user precedes bounded/deduplicated /api/v1/user/repos; Compose exposes localized signed-out, browser-waiting/cancel, loading, content, empty, offline, permission, expired-auth, callback, and server-error states.
• Files changed: Android manifest and extraction rules, network/auth/repository data layers, repository ViewModel/Compose screen, dependencies/resources, focused tests, and TASK-002B/004/005/011 status documentation.
• Checks and results: Debug APK build passed; 57 unit tests across 16 suites passed; Android lint passed; diff and sensitive-pattern checks passed; no WebView or production client secret exists.
• Review findings and resolutions: Browser cancellation dead-end, HTTP response-read exception handling, signed-in error recovery/logout, nullable DTO validation, immutable UI snapshots, and bounded pagination coverage were fixed. Final independent re-review reported no remaining P0/P1.
• Known limitations: No Android device is connected, so the hosted App Link, system-browser return, live account login, repository result, and device Keystore behavior require one manual E2E run on the target phone.
• Next recommended task: Install the debug APK on the target Android device and verify login plus the internal repository list; after that, begin branch browsing.
• Next owner: Human product owner for device E2E, then Codex.

2026-08-25 — TASK-011 device E2E closure

• Agent and role: Human product owner, device verifier; Codex, evidence recorder
• Verification performed: Installed application login against the production company Gitea and retrieval of the authenticated account's internal repository list.
• Result: System-browser OAuth, verified App Link return, authenticated API access, and repository-list rendering passed on the target device.
• Review status: Automated gates previously passed and final independent review reported no P0/P1; the remaining manual device gate is now closed.
• Task status: TASK-011 complete.
• Next recommended task: Add repository selection and branch listing.
• Next owner: Codex.

2026-08-25 — TASK-012

• Agent and role: Codex, workflow implementer
• Commit/diff: TASK-012 documentation diff
• Features implemented: Durable current-state and remaining-roadmap handoff, Claude working-style prompt, and bidirectional append-only question/answer mailboxes.
• How it was implemented: Writer-specific directories and immutable per-message files preserve the single-writer protocol; the roadmap orders work by frozen-contract dependencies and assigns one owner per task.
• Files changed: handoff/, TASK-006A status, TASK-012, collaboration documentation, and this log.
• Checks and results: Documentation paths, baseline commits, ownership, task dependencies, and mailbox cross-references inspected; no Android code or external infrastructure changed.
• Review findings and resolutions: Pending Claude read-only review of the handoff package.
• Known limitations: Mailboxes coordinate repository-based handoff and do not provide real-time notification; agents must inspect them at task start.
• Next recommended task: Claude implements TASK-006A only and hands its commit to Codex for review.
• Next owner: Claude.

2026-08-25 — TASK-012 review closure and activation

• Agent and role: Codex, finding resolver and handoff owner; Claude, independent read-only reviewer
• Commit/diff: reviewed package commit 57d1c09; immutable activation ref handoff/task-006a-ready
• Findings resolved: Canonical delivery sequence now explicitly permits independent TASK-006A before the TASK-004/005 remainder; TASK-006A authorizes only its completion-log append; both mailbox directions share symmetric immutable templates and unique correction filenames; completed OAuth evidence is synchronized.
• Checks and results: Documentation cross-references and task dependencies inspected; git diff --check passed before activation; no Android production file or external infrastructure changed.
• Review result: No handoff activation occurs until the tag resolves to the committed metadata state. Claude checks out the tag, creates a claude/ branch, implements TASK-006A only, and then stops for Codex review.
• Known limitation: Repository mailboxes are asynchronous and must be checked manually at task start.
• Next owner: Claude for TASK-006A.

2026-08-25 — TASK-006A implementation

• Agent and role: Claude, assigned feature implementer (writable scope limited to feature/codebrowser/content/ and this task's evidence/log entries)
• Commit/diff: branch claude/task-006a-ready created from activation tag handoff/task-006a-ready (base 965d55d); implementation adds ContentClassification.kt, SourceContentClassifier.kt, and SourceContentClassifierTest.kt under feature/codebrowser/content/
• Features implemented: Pure-Kotlin classifier that turns already-loaded SourceContent bytes into one of five immutable states — bounded text (with independent line/character truncation flags), binary, Git LFS pointer, unsupported encoding, or oversized — using caller-supplied positive byte/character/line limits.
• How it was implemented: Oversized input is rejected by raw byte count before any decoding; binary is detected by a raw NUL-byte scan; text decoding uses a strict UTF-8 CharsetDecoder with CodingErrorAction.REPORT for malformed and unmappable input so it never substitutes replacement characters; a Git LFS pointer is recognized only from the exact canonical version line followed by valid oid sha256:<64 hex> and size <integer> lines within the 1024-byte spec bound; remaining text is truncated independently by line count and character count with an explicit isTruncated flag. No shared domain, data, Gradle, manifest, or navigation file was modified; RepositoryModels.kt/RepositoryPath.kt/RepositoryRef.kt remain identical to contract-freeze commit 0929282.
• Files changed: app/src/main/java/com/ubisam/ubgitea/feature/codebrowser/content/ContentClassification.kt, app/src/main/java/com/ubisam/ubgitea/feature/codebrowser/content/SourceContentClassifier.kt, app/src/test/java/com/ubisam/ubgitea/feature/codebrowser/content/SourceContentClassifierTest.kt, tasks/006a-code-content-classifier.md (evidence/status), this log entry.
• Checks and results: ./gradlew testDebugUnitTest --tests "com.ubisam.ubgitea.feature.codebrowser.content.*" passed (25/25); ./gradlew assembleDebug testDebugUnitTest lintDebug --rerun-tasks passed (82 unit tests repository-wide, 0 failures; lint 0 errors, 22 pre-existing warnings unchanged from TASK-001 baseline); git diff --check clean; sensitive-pattern scan of changed files found no secret/token/password/private-key markers.
• Review findings and resolutions: None yet — pending Codex read-only review.
• Known limitations: No Android device/emulator was used, since this task has no Android framework dependency (pure JVM-testable Kotlin); static formatting/check task remains unconfigured for the module.
• Next recommended task: Codex reviews this commit read-only per docs/workstreams.md cross-review rules; TASK-006 UI remains blocked until Codex freezes the TASK-004/005 contracts.
• Next owner: Codex, for review.

2026-08-26 — TASK-006A Codex integration review

• Agent and role: Codex, integrator and reviewer
• Commit/diff: Claude commit 979729a, integrated as 4f5faf3, plus Codex Unicode-boundary fix
• Review findings and resolutions: One P2 was found: UTF-16 substring truncation could split an emoji or another supplementary character into a lone surrogate. Rendering now counts and truncates Unicode code points, with a focused emoji regression test.
• Checks and results: Focused classifier, full unit-test, debug-build, lint, diff, and sensitive-pattern gates are rerun after the fix.
• Known limitations: TASK-006 remains blocked on completion and freeze of the TASK-004/005 API and navigation contracts.
• Next recommended task: Codex completes the TASK-004 branch/tag/tree/file API remainder, then TASK-005 repository selection and branch browsing.
• Next owner: Codex.

2026-08-26 — TASK-004

• Agent and role: Codex, implementer and integrator
• Commit/diff: TASK-004 working diff following ed2121b
• Features implemented: Authenticated read-only repository, branch, tag, directory-tree, Base64 source-file, and commit API adapter with immutable pagination.
• How it was implemented: OkHttp HttpUrl encodes every owner/repository/path segment and ref/path query independently; private nullable Gson DTOs validate before mapping; bearer-token access is injected; contents arrays are locally paged; file type/path/encoding/size are verified; HTTP and network outcomes use typed failures.
• Files changed: Core network failures, repository data adapter/tests, tag domain/use-case contracts, HTTP decision ADR, Gradle test dependency, TASK-004 evidence, and this log.
• Checks and results: Focused in-memory and MockWebServer tests passed; repository-wide debug build and lint passed; 90 unit tests across 19 suites passed with zero failures/errors; diff check and focused sensitive-pattern scan passed.
• Review findings and resolutions: Self-review added page-overflow protection, returned-file path matching, nullable size validation, Unicode-safe prior classifier integration, and a real local HTTP boundary test.
• Known limitations: Gitea contents has no server-side pagination, so later directory pages repeat the request and slice the immutable returned snapshot locally.
• Review status: Codex completed source/contract self-review. Independent review is deferred while the user has assigned the serial implementation stream to Codex and must be completed before TASK-006 contract freeze.
• Next recommended task: TASK-005 repository selection and branch/tag browsing UI.
• Next owner: Codex.

2026-08-26 — TASK-005

• Agent and role: Codex, implementer and integrator.
• Commit/diff: TASK-005 working diff following 8a47d30; the exact completion commit is recorded after commit creation.
• Features implemented: Repository selection plus repository-scoped branch and tag browsing, default/protected/selected reference indicators, abbreviated commit IDs, refresh, retry, logout, and deterministic back navigation.
• How it was implemented: A unidirectional immutable ViewModel state machine consumes the TASK-004 read-only browser contract, loads bounded pages serially, deduplicates references by name, cancels replaced work, and restores the cached repository-list snapshot. Small gateway interfaces make authentication and repository restoration JVM-testable without Android framework construction.
• Files changed: Repository Compose/ViewModel/presenter and tests, MainActivity callback wiring, testable authentication/repository gateway boundaries, localized repository strings, and TASK-005 evidence.
• Checks and results: Focused presenter/ViewModel tests passed; repository-wide debug build, 96 unit tests across 21 suites, and Android lint passed; diff and focused sensitive-pattern checks passed.
• Review findings and resolutions: Self-review added immutable reference snapshots, operation cancellation on back navigation, typed reference errors retaining repository context, and ViewModel tests for selection/restoration/error behavior. Independent review is deferred while Codex owns the serial stream.
• Known limitations: No device/emulator interaction test was available in this work cycle. The reviewed contract-freeze checkbox remains open until independent integration review.
• Next recommended task: TASK-006 directory navigation and bounded source-file viewing using the TASK-004 API and reviewed TASK-006A classifier.
• Next owner: Codex for continuous implementation; Claude may later perform the independent review when re-enabled by the product owner.

2026-08-26 — TASK-006

• Agent and role: Codex, temporary feature implementer and integrator while Claude work is paused.
• Commit/diff: TASK-006 working diff based on TASK-005 commit bbbff77; exact implementation commit recorded after creation.
• Features implemented: Explicit branch/tag tree browsing, deterministic breadcrumbs and back navigation, directory/file selection, bounded selectable/copyable source text, and dedicated binary/LFS/unsupported-encoding/oversized/symlink/submodule fallbacks.
• How it was implemented: A feature-owned immutable ViewModel state machine passes repository coordinates, ref, and validated path to every TASK-004 read-only request. It consumes bounded pages serially, cancels replaced work, retains file-vs-directory retry intent, and delegates byte classification to the reviewed TASK-006A component. The Compose screen keeps repository/ref/path visible and virtualizes directory rows.
• Files changed: Code-browser ViewModel, navigation helper, Compose screen, Korean resources, focused tests, MainActivity feature wiring, selected-reference handoff, and TASK-006 evidence.
• Checks and results: Focused code-browser tests passed; repository-wide debug build, 102 unit tests across 23 suites, and Android lint passed; diff and focused sensitive-pattern/read-only scans passed.
• Review findings and resolutions: Self-review fixed root-loading back behavior, file retry incorrectly becoming a directory request, file breadcrumbs attempting directory loads, configuration-change screen loss, and non-virtualized directory rendering. Independent review is deferred.
• Known limitations: Physical-device interaction has not yet been rerun. TASK-005's reviewed contract-freeze criterion remains open pending later independent review.
• Next recommended task: TASK-009 immutable history/change/diff API contracts, followed by TASK-007 read-only history and change UI.
• Next owner: Codex for the continuous serial stream.

2026-08-26 — TASK-004/005/006 independent review and freeze

• Agent and role: Claude, independent reviewer per handoff/claude-master-handoff.md's "review and freeze" first action; human product owner authorized Claude as incoming primary implementer with handback to Codex kept possible at any time.
• Commit/diff: reviewed 8a47d30 (TASK-004), bbbff77 (TASK-005), 16c46a5 (TASK-006) read-only, then fixed one finding on branch claude/review-005-006-freeze from 16c46a5.
• Review scope and method: Independently reran assembleDebug testDebugUnitTest lintDebug --rerun-tasks (did not trust the recorded evidence alone) and read GiteaRepositoryBrowserApi.kt, HttpTransport.kt, RepositoryListViewModel.kt, RepositoryReferencePresenter.kt, CodeBrowserViewModel.kt, CodeBrowserNavigation.kt, and MainActivity.kt against the master handoff's checklist: races/cancellation, root back, rotation restoration, URL encoding, immutable snapshots, page overflow, and 404/409/422 mapping. TASK-009's commit was not yet available (still uncommitted upstream) and was excluded from this pass per human product owner direction.
• Findings:
  • P2 (fixed): core/network/HttpTransport.kt requireSuccess() mapped 401/403/404/429/5xx but let 409 and 422 fall through to the generic ApiFailure.InvalidResponse, which would have blocked TASK-007's planned conflict/unprocessable UDF states. Added ApiFailure.Conflict/ApiFailure.Unprocessable and extended GiteaRepositoryBrowserApiTest's status-mapping test.
  • P3 (recorded, not fixed): CodeBrowserViewModel runs JSON parsing, Base64 decoding, directory sort/dedupe, and the TASK-006A classifier on viewModelScope's Main dispatcher after the network suspend point resumes. Not blocking; recommended for TASK-016 (release hardening) given its low-end-device and large-content scope.
  • Everything else checked (races/cancellation, root back via BackHandler in both screens, immutable snapshot wrapping, page-overflow bounds, URL component encoding) verified correct with no finding.
• Checks and results after the fix: assembleDebug testDebugUnitTest lintDebug --rerun-tasks BUILD SUCCESSFUL, 102 unit tests across 23 suites, 0 failures/errors, 0 lint errors; git diff --check clean; sensitive-pattern scan clean (one match was a test asserting client_secret absence, not a leak).
• Task evidence updated: TASK-004, TASK-005, and TASK-006 each record this closure. TASK-005's "reviewed completion commit is TASK-006's contract-freeze base" and TASK-006's "evidence records the exact reviewed TASK-005 contract-freeze commit" checkboxes are both closed. TASK-009's corresponding freeze checkbox remains open pending its own commit and review.
• Known limitations: No physical device was available, so device-interaction checks named in TASK-005/006 remain deferred, unchanged from before this review.
• Next recommended task: TASK-007 (history and change UI), per the ordered backlog in handoff/claude-master-handoff.md, once TASK-009 lands and is reviewed; TASK-010 (work-item API contracts) ownership is transferred to Claude per the same handoff.
• Next owner: Claude, continuing the primary implementer role with handback to Codex available at any time by flipping a task's Owner field back and picking up from its last recorded commit.

2026-08-26 — TASK-017: recent-push sort, paged repository list, last-pushed branch

• Agent and role: Claude, feature implementer, per human product owner priority-1 request in conversation on 2026-08-26.
• Commit/diff: branch claude/task-017-recent-push-favorites from fdda164; new task file tasks/017-repository-list-recent-push.md.
• Features implemented: Repository list is now sorted most-recently-pushed-first (server-side sort=updated&order=desc, correct across page boundaries), paged 5 at a time with explicit previous/next navigation, and each visible repository independently shows (and can retry) its most recently committed branch.
• How it was implemented: Added updatedAtEpochMillis to RepositorySummary and commitAtEpochMillis to BranchSummary, mapped from Gitea's updated_at and branch commit.timestamp. Replaced the legacy eager-loading RepositoryListApi/AccessibleRepositoriesGateway with the existing paged GiteaRepositoryBrowser.listRepositories. RepositoryListViewModel now tracks a page number and launches one cancellable job per visible row to fetch and compare that repository's branch timestamps; jobs are cancelled on page change/refresh/navigation-away and resumed (not restarted) when returning via back-navigation.
• Files changed: domain/model/RepositoryModels.kt, data/repositories/GiteaRepositoryBrowserApi.kt, removed data/repositories/RepositoryListApi.kt and its test, feature/repositories/RepositoryListViewModel.kt, feature/repositories/RepositoryListScreen.kt, MainActivity.kt, strings_repositories.xml, associated tests, tasks/017-repository-list-recent-push.md.
• Checks and results: assembleDebug testDebugUnitTest lintDebug --rerun-tasks BUILD SUCCESSFUL — 105 unit tests across 22 suites, 0 failures/errors, 0 lint errors; git diff --check clean (CRLF notices only); sensitive-pattern scan clean.
• Review findings and resolutions: Self-review caught and fixed two issues before they shipped: (1) page-navigation/refresh calls had no try/catch, which would have crashed the app on any network failure during nextPage()/previousPage()/refreshRepositories() — wrapped in the same error-mapping pattern used elsewhere; (2) a repository with no default branch (a real Gitea state for empty repos) would have failed the entire page load via the existing fail-closed .required() mapping — defaultBranch is now nullable at the domain level, matching how the UI already handled it. Independent Codex review is pending.
• Known limitations: No physical device was available to verify page navigation and per-row branch loading interactively. Timestamp ties between two branches resolve deterministically but arbitrarily (first match kept).
• Next recommended task: TASK-018 (Gitea-star favorites tab), already scoped in tasks/018-favorites-gitea-star.md, is next; Codex review of TASK-017 can happen in parallel since it touches non-overlapping paths once merged.
• Next owner: Codex for read-only review of TASK-017; Claude continuing to TASK-018.

2026-08-26 — TASK-018: Favorites tab backed by Gitea star

• Agent and role: Claude, feature implementer, per human product owner priority-1 request in conversation on 2026-08-26 (same request as TASK-017).
• Commit/diff: same branch as TASK-017 (claude/task-017-recent-push-favorites), committed as a separate commit on top of it; new task file tasks/018-favorites-gitea-star.md, ADR docs/decisions/004-favorites-write-user-scope.md.
• Features implemented: A user can star a repository from the main list and unstar it from a new Favorites tab, which shows only their starred repositories with the same paging/loading/empty/error states as the main list.
• How it was implemented: Added write:user to the app's requested OAuth scopes and replaced OAuthClientConfig's "every scope must be read-only" guard with "every scope must be read-only or in an explicit approved-write-scope allow-list" (currently exactly write:user) — the app's first non-read-only scope and first write endpoint. HttpTransport gained bearer-authenticated put/delete. GiteaRepositoryBrowserApi now also implements a new RepositoryFavorites domain interface (listStarred/star/unstar) on the same class, reusing its existing repository-mapping code. RepositoryListViewModel gained a RepositoryListMode (ALL/FAVORITES) carried on its Content/Empty states; toggling favorite either marks a row Starred (ALL mode, confirmed-not-optimistic) or removes it from the current page (FAVORITES mode, after a confirmed unstar). RepositoryListScreen gained a tab switcher and a per-row favorite button using plain localized text (no new icon dependency).
• Files changed: core/auth/protocol/OAuthClientConfig.kt, core/network/HttpTransport.kt, data/repositories/GiteaRepositoryBrowserApi.kt, new domain/repository/RepositoryFavorites.kt, feature/repositories/RepositoryListViewModel.kt, feature/repositories/RepositoryListScreen.kt, MainActivity.kt, strings_repositories.xml, associated tests, new OAuthClientConfigTest.kt, ADR-004, tasks/018-favorites-gitea-star.md.
• Checks and results: assembleDebug testDebugUnitTest lintDebug --rerun-tasks BUILD SUCCESSFUL — 117 unit tests across 23 suites, 0 failures/errors, 0 lint errors; git diff --check clean (CRLF notices only); sensitive-pattern scan clean.
• Review findings and resolutions: Self-review narrowed two acceptance criteria from their original draft to match what was actually and deliberately built: favorite-toggle failures use one generic retryable state rather than per-HTTP-status messages (proportionate for a lightweight toggle), and favorite state updates only after a confirmed server response rather than optimistically. Independent Codex review is pending, and this is the first task to also request on-device verification of the new OAuth scope specifically (does the Gitea instance's OAuth app registration accept it without a server-side change).
• Known limitations: No physical device was available — the new-scope login path is unverified. Existing signed-in users need one fresh login before Favorites works. Favorite state is never cached locally (always read fresh from Gitea).
• Next recommended task: Codex reviews TASK-017 and TASK-018 together (same branch) and verifies the write:user login on a physical device before this reaches users; TASK-007 (history UI) remains next in the original roadmap once TASK-009 lands.
• Next owner: Codex, for review and device verification.

2026-08-26 — TASK-010: pull-request and issue API contracts

• Agent and role: Claude, feature implementer (ownership transferred by human product owner in handoff/claude-master-handoff.md), continuing work per the human product owner's "진행해줘" (proceed) instruction while TASK-009 remained uncommitted on Codex's side.
• Commit/diff: branch claude/task-010-work-items-contract from 525a0aa; new domain/workitems/ and data/workitems/ packages.
• Features implemented: Frozen, read-only domain and data contracts for pull requests, issues, reviews, and comments — listIssues/getIssue/listIssueComments, listPullRequests/getPullRequest/listPullRequestReviews/listPullRequestComments.
• How it was implemented: IssueSummary/IssueDetail and PullRequestSummary/PullRequestDetail are fully separate models. WorkItemAuthor is Known/Unavailable so a deleted or null author never becomes an invented name. PullRequestState is derived from Gitea's merged flag combined with its open/closed state (there is no single field that already encodes "merged"). listIssues drops entries whose pull_request field is non-null so Gitea's issue-list endpoint (which also returns PRs) never duplicates what listPullRequests already exposes — done client-side rather than trusting a guessed, unverified query parameter. PR/issue discussion comments both reuse /issues/{number}/comments, matching how Gitea treats PRs as issues internally. Reused domain.model.Page<T> and core.network.ApiFailure rather than introducing parallel types.
• Files changed: domain/workitems/WorkItemModels.kt, domain/workitems/WorkItemsRepository.kt, data/workitems/GiteaWorkItemsApi.kt, data/workitems/GiteaWorkItemsApiTest.kt, tasks/010-work-items-api-contract.md.
• Checks and results: assembleDebug testDebugUnitTest lintDebug --rerun-tasks BUILD SUCCESSFUL — 128 unit tests across 24 suites, 0 failures/errors, 0 lint errors; git diff --check clean; sensitive-pattern scan clean; grep-confirmed no put/delete/postForm call anywhere in the new API class (read-only, as required).
• Review findings and resolutions: None — self-review found no P0-P3. Independent Codex review and contract-freeze recording are still required before TASK-008 (the UI that consumes this contract) may begin.
• Known limitations: Gitea's exact issue/PR filtering query-parameter behavior was not confirmed against authoritative live documentation; the client-side pull_request-field filter is correct regardless, at the cost of potentially shorter-than-requested pages after filtering. No physical device or live Gitea instance was used — coverage is fake-transport/unit-level only, consistent with how TASK-004/009 were verified before their own freeze review.
• Next recommended task: Codex reviews and freezes this contract; TASK-008 (PR/issue UI) can then begin. TASK-007 remains blocked on TASK-009 independently.
• Next owner: Codex, for review and contract-freeze recording.

2026-08-26 — TASK-009: history and diff API contracts

• Agent and role: Claude, feature implementer, at the human product owner's explicit direction ("그냥 코덱스 말고 너가 다시 작업해줘" — implement it yourself instead of Codex) rather than continue waiting on Codex's separate, still-uncommitted attempt in the primary worktree.
• Commit/diff: branch claude/task-009-history-diff-contract from 7d122d4; new domain/history/ and data/history/ packages. Codex's parallel uncommitted attempt at the same task was not read or referenced, to keep this an independent implementation.
• Features implemented: Commit detail with per-file added/modified/deleted/renamed/other status, bounded commit and comparison patch/diff text with an explicit truncated flag, and ref comparison with locally-computed pagination.
• How it was implemented: Verified Gitea's actual response shapes against its own Go source (modules/structs/repo_commit.go, compare.go field names) rather than guessing. Deliberately did not duplicate commit-history listing, since TASK-004's GiteaRepositoryBrowser.listCommits already provides it. Patch text comes from Gitea's .diff-suffixed raw-text endpoints (not the JSON commit/compare objects, which only carry file status, not diff content) and is bounded by byte limit then line limit, both constructor-injected and validated positive. The compare endpoint's single combined base...head path segment is built by concatenating both ref values before one addPathSegment call, so each ref (including any / in a branch name) is escaped exactly once — verified by a test using a ref containing a slash. Comparison pagination is computed locally against Gitea's one-shot compare response, reusing the same slicing pattern TASK-004 already uses for tree listing.
• Files changed: domain/history/HistoryModels.kt, domain/history/HistoryRepository.kt, data/history/GiteaHistoryApi.kt, data/history/GiteaHistoryApiTest.kt, tasks/009-history-diff-api-contract.md.
• Checks and results: assembleDebug testDebugUnitTest lintDebug --rerun-tasks BUILD SUCCESSFUL — 141 unit tests across 25 suites, 0 failures/errors, 0 lint errors; git diff --check clean; sensitive-pattern scan clean; grep-confirmed no put/delete/postForm call in the new API class.
• Review findings and resolutions: None — self-review found no P0-P3. Two items flagged for reviewer attention rather than treated as settled: the exact Gitea file-status vocabulary beyond added/modified/deleted/renamed was not exhaustively confirmed, and the .diff-suffixed compare route was inferred from the documented single-commit convention rather than independently verified.
• Known limitations: No physical device or live Gitea instance was used. Codex was independently attempting this same task in parallel (uncommitted); this entry and this implementation exist alongside that one and the two need to be reconciled by whoever reviews, not assumed to be the same.
• Next recommended task: Codex (or whoever reviews) reconciles this implementation against its own parallel TASK-009 attempt, reviews, and records the contract-freeze commit so TASK-007 can begin.
• Next owner: Codex, for reconciliation, review, and contract-freeze recording.

2026-08-26 — TASK-007: commit history and change UI

• Agent and role: Claude, feature implementer, per the human product owner's direction that Claude owns all subsequent tasks rather than Codex ("이후 다른 작업들도 코덱스 말고 너가 다 작업해줘").
• Commit/diff: branch claude/task-007-history-ui from 3c17476 (this session's own TASK-009, not yet Codex-reviewed); new feature/history/ package plus MainActivity.kt and CodeBrowserScreen.kt wiring.
• Features implemented: Paginated commit history for the currently browsed ref; commit detail with distinguished added/modified/deleted/renamed file status; bounded, explicitly-truncated patch text for a single commit or a ref comparison; a comparison flow that validates one entered ref against the currently open ref as base.
• How it was implemented: Reuses TASK-004's listCommits for history listing and this session's own TASK-009 HistoryRepository for detail/patch/compare — no shared/domain file touched. A commit's file list and its patch load as two independently-retryable steps rather than one blocking fetch. Entry point is a new "히스토리" button added to the existing code browser header, wired through a third browsingHistory screen flag in MainActivity layered above the existing browsingCode flag.
• Files changed: feature/history/HistoryViewModel.kt, feature/history/HistoryScreen.kt, strings_history.xml, MainActivity.kt, feature/codebrowser/CodeBrowserScreen.kt, strings_codebrowser.xml, tasks/007-history-and-changes.md.
• Checks and results: assembleDebug testDebugUnitTest lintDebug --rerun-tasks BUILD SUCCESSFUL — 150 unit tests across 26 suites, 0 failures/errors, 0 lint errors; git diff --check clean; sensitive-pattern scan clean.
• Review findings and resolutions: Self-review caught and fixed one real bug before writing tests: a failed commit-detail fetch discarded which commit had failed, so "retry" silently fell back to reloading the whole list instead of re-fetching the commit the user actually tried to open. The Error state now retains the failed CommitSummary so retry targets the same commit.
• Known limitations: TASK-009 has not been independently reviewed or contract-frozen — this task consumes it directly, with no cross-review from a second implementer, per explicit human direction. No physical device was available to verify the three-level back stack (repositories → code browser → history) interactively. Comparison always uses the open ref as base (no arbitrary base-ref picker); comparison patch is fetched once for the whole range, not per commit.
• Next recommended task: TASK-010 is already done (this session); TASK-008 (PR/issue UI) is next and consumes it the same way TASK-007 consumed TASK-009 — directly, without waiting for Codex review, per the same standing direction.
• Next owner: Claude, continuing to TASK-008.

2026-08-26 — TASK-008: pull-request and issue UI

• Agent and role: Claude, feature implementer, continuing the standing direction that Claude owns all subsequent tasks without stopping to ask between them.
• Commit/diff: branch claude/task-008-workitems-ui from 429668b; new feature/workitems/ package plus MainActivity.kt and RepositoryListScreen.kt wiring.
• Features implemented: Separate issue and PR list/detail views (tabs), paginated, with comments (issues) and reviews+comments (PRs); deleted/unavailable authors render a fixed placeholder instead of crashing or inventing identity; every status is a text label, never color-only.
• How it was implemented: Reuses TASK-010's domain contracts directly — no shared/domain file touched. Both list types apply distinctBy(number) per page and use the same discrete prev/next paging convention as TASK-017/007, which structurally prevents duplicate rows without separate merge logic. Entry point is a new button on the repository references screen (issues/PRs are repository-scoped, not ref-scoped, unlike history).
• Files changed: feature/workitems/WorkItemsViewModel.kt, feature/workitems/WorkItemsScreen.kt, strings_workitems.xml, MainActivity.kt, feature/repositories/RepositoryListScreen.kt, strings_repositories.xml, tasks/008-work-items-ui.md.
• Checks and results: assembleDebug testDebugUnitTest lintDebug --rerun-tasks BUILD SUCCESSFUL — 158 unit tests across 27 suites, 0 failures/errors, 0 lint errors; git diff --check clean; sensitive-pattern scan clean.
• Review findings and resolutions: None — self-review found no P0-P3.
• Known limitations: TASK-010 has not been independently reviewed or contract-frozen. No physical device or instrumented Compose test verified accessibility semantics interactively (consistent with every other feature this session). Pagination dedupe is verified within a single page's response, not across an accumulating infinite scroll.
• Next recommended task: This closes the originally-scoped TASK-007/008 pair. Remaining roadmap items (TASK-013 navigation, TASK-014 organizations, TASK-015 notifications, TASK-016 release hardening) have no task files yet.
• Next owner: Claude.

2026-08-26 — TASK-013: typed application navigation

• Agent and role: Claude, feature implementer, continuing the standing direction to own all subsequent tasks without asking between them. No task file existed for TASK-013 beforehand (only proposed in an earlier handoff document); created it first per AGENTS.md.
• Commit/diff: branch claude/task-013-navigation from c397fbe; new ui/navigation/ package, rewrote MainActivity.kt.
• Features implemented: Replaced MainActivity's three independent booleans with one typed List<Route> back stack, restorable through configuration change and process death.
• How it was implemented: Route is a sealed type of stable primitives only (owner/name/ref/ref-kind — never tokens or content). RouteStackSaver encodes each route as a delimiter-joined string using U+001F, a character RepositoryCoordinates/RepositoryRef already guarantee can never appear in real field values. A single LaunchedEffect(currentRoute) re-triggers the owning feature ViewModel's load whenever the top route changes, covering both fresh navigation and restoration identically. This is a genuine behavior improvement, not just a refactor: the stack is a real LIFO, so back correctly unwinds through arbitrarily nested screens instead of relying on which boolean happened to still be true underneath another.
• Files changed: ui/navigation/Route.kt, ui/navigation/RouteStackSaver.kt, RouteEncodingTest.kt, MainActivity.kt, tasks/013-typed-navigation.md.
• Checks and results: assembleDebug testDebugUnitTest lintDebug --rerun-tasks BUILD SUCCESSFUL — 164 unit tests across 28 suites, 0 failures/errors, 0 lint errors; git diff --check clean; sensitive-pattern scan clean.
• Review findings and resolutions: None functional. One implementation detail worth recording: Compose's listSaver actually returns Saver<List<T>, Any>, not Saver<List<T>, List<Saveable>> as its type parameters suggest — found via the compiler's own type-mismatch error rather than assumed, and RouteStackSaver's declared type corrected to match.
• Known limitations: Only the route itself survives process death, not deeper in-feature state (open commit, scroll position) — explicitly out of scope. No physical device was available to verify process-death restoration interactively; the Saver round-trip is unit-tested directly instead.
• Next recommended task: TASK-014 (organizations) and TASK-015 (notifications) are real MVP scope items from docs/product.md with no task files yet; TASK-016 (release hardening) depends on those and needs a physical device. Continuing per standing direction.
• Next owner: Claude.

2026-08-26 — TASK-014: organizations and organization repository filter

• Agent and role: Claude, feature implementer, continuing the standing direction to own all subsequent tasks. No task file existed beforehand; created it first per AGENTS.md. Closes MVP outcome #2 in docs/product.md ("View the signed-in user and organizations").
• Commit/diff: branch claude/task-014-organizations from 7756ec4; new domain/organizations/ package, additive changes to GiteaRepositoryBrowserApi/RepositoryListViewModel/RepositoryListScreen.
• Features implemented: The repository list can be filtered to one organization (a horizontally-scrollable chip row: 전체 + one per org) and back, keeping the existing recent-push sort and paging.
• How it was implemented: Verified Gitea's actual Organization struct (name/full_name) before implementing. GiteaRepositoryBrowserApi gained a third interface (OrganizationsRepository), reusing its existing mapRepository for org-scoped repos rather than duplicating mapping. The organizations list itself is fetched once per session and cached, since it changes rarely and every page load re-fetching it would be wasteful; a failure to load it degrades to an empty filter row rather than blocking the repository list, which is the primary content.
• Files changed: domain/organizations/OrganizationModels.kt, domain/organizations/OrganizationsRepository.kt, GiteaRepositoryBrowserApi.kt, GiteaRepositoryBrowserApiTest.kt, RepositoryListViewModel.kt, RepositoryListViewModelTest.kt, RepositoryListUiStateTest.kt, RepositoryListScreen.kt, strings_repositories.xml, MainActivity.kt, tasks/014-organizations.md.
• Checks and results: assembleDebug testDebugUnitTest lintDebug --rerun-tasks BUILD SUCCESSFUL — 169 unit tests across 28 suites, 0 failures/errors, 0 lint errors; git diff --check clean; sensitive-pattern scan clean.
• Review findings and resolutions: None — self-review found no P0-P3.
• Known limitations: No physical device or real multi-organization account was available to verify interactively. Organization membership is read once per session, not refreshed mid-session (matches the app's existing no-background-refresh posture).
• Next recommended task: TASK-015 (notifications) is the last remaining MVP-scope item without a task file; TASK-016 (release hardening) depends on it and needs a physical device.
• Next owner: Claude.

2026-08-26 — TASK-015: read-only notifications

• Agent and role: Claude, feature implementer, continuing the standing direction to own all subsequent tasks without stopping to ask between them ("따로 말하지말고 알아서 계속 다음 작업 진행해줘"). No task file existed beforehand; created it first per AGENTS.md. Closes the last remaining MVP-scope item from docs/product.md.
• Commit/diff: branch claude/task-015-notifications from 4fe3bf1; new domain/notifications/, data/notifications/, feature/notifications/ packages, additive changes to Route.kt/RouteStackSaver.kt/MainActivity.kt/RepositoryListScreen.kt.
• Features implemented: A signed-in user can view their Gitea notifications (unread-only, the endpoint's own default, or all), paginated, and tap one whose subject is a navigable issue/PR to jump to that repository's work items. No mark-read/unread/pinned write endpoint is reachable from any new code — deliberately excluded, same posture as the star/unstar write scope decision (ADR-004).
• How it was implemented: Verified Gitea's actual NotificationThread/NotificationSubject struct shape via its own Go source before implementing. Subject type/state fall back to OTHER/UNKNOWN on an unrecognized value instead of failing closed. The subject's issue/PR number has no dedicated field in the API — it is parsed from the trailing path segment of the subject URL, yielding null (not a guess) when unparseable, which is exactly the case for commit/repository-type subjects. Unread state renders as a [읽지 않음] text label, never color alone. Self-review caught the same class of bug as TASK-007's history-retry issue: the first draft's Error state didn't retain which filter was active, so retrying after a failure while viewing "전체" would have silently reset to "읽지 않음" — fixed by adding unreadOnly to Error, with a regression test.
• Files changed: domain/notifications/NotificationModels.kt, domain/notifications/NotificationsRepository.kt, data/notifications/GiteaNotificationsApi.kt, data/notifications/GiteaNotificationsApiTest.kt, feature/notifications/NotificationsViewModel.kt, feature/notifications/NotificationsScreen.kt, feature/notifications/NotificationsViewModelTest.kt, strings_notifications.xml, ui/navigation/Route.kt, ui/navigation/RouteStackSaver.kt, MainActivity.kt, feature/repositories/RepositoryListScreen.kt, tasks/015-notifications.md.
• Checks and results: assembleDebug testDebugUnitTest lintDebug --rerun-tasks BUILD SUCCESSFUL — 188 unit tests total, 0 failures/errors, 0 lint errors; git diff --check clean; sensitive-pattern scan clean.
• Review findings and resolutions: None beyond the retry-filter bug caught and fixed during self-review (see above). One item flagged for reviewer attention rather than treated as settled: applying status-types=unread&status-types=read to the notification-list endpoint to request "전체" was not independently verified against a live Gitea instance — Gitea's public docs describe that parameter only on the per-repo mark-read endpoint; if wrong, the fallback is two separate calls merged client-side.
• Known limitations: Tapping an issue/PR notification opens that repository's work-item list, not the specific item's detail — Route.WorkItems (TASK-013) carries no item number, and adding one was out of this task's scope. No physical device was available to verify interactively.
• Next recommended task: TASK-016 (release hardening) is the last item on the proposed roadmap; it depends on TASK-014/015 (both now done) and was previously noted as needing a physical device, which remains unavailable in this environment — will surface that as a genuine blocker rather than skip it silently.
• Next owner: Claude.

2026-08-26 — TASK-016: release hardening (partial — device-dependent items explicitly blocked)

• Agent and role: Claude, feature implementer, continuing the standing direction to own all subsequent tasks. No task file existed beforehand; created it first per AGENTS.md.
• Commit/diff: continued on claude/task-015-notifications (no separate branch cut for this small follow-on); changes to CodeBrowserViewModel.kt/CodeBrowserViewModelTest.kt, new tasks/016-release-hardening.md.
• Features implemented: Fixed the P3 dispatcher issue recorded during the TASK-004/005/006 review — CodeBrowserViewModel now runs directory listing/dedupe/sort and file fetch+classification on an injectable defaultDispatcher (Dispatchers.Default in production) instead of viewModelScope's Main dispatcher.
• How it was implemented: An AVD (WhatToEat_API_36) turned out to be available in this environment — confirmed with the human product owner before using it, after they clarified an emulator should exist (Codex had used one on a different project). Booted it and ran a pre-authentication smoke test: cold install, launch, sign-in screen renders correctly (localized Korean text), tapping "Gitea로 로그인" correctly hands off to the system browser toward the OAuth flow, no crash. Attempting to click through Chrome's first-run screen to test further hit a hard constraint, not a tooling gap: completing Gitea login requires entering a password, which is a universally prohibited action in this agent's safety rules regardless of whose credentials are offered — one blind tap nearly walked into Chrome's "add a Google account" flow, which was backed out of immediately (am force-stop) without proceeding. Confirmed with the human product owner (2026-08-26) how to proceed: do everything verifiable without login, leave the rest explicitly blocked rather than attempted or silently skipped. Also ran a full-repository secret scan (not scoped to one diff), reviewed the manifest/backup-rules/token-vault security posture (all already correct — allowBackup="false", data_extraction_rules.xml excludes all sharedpref data, AES/GCM via Android Keystore, no Log.*/println anywhere in app/src/main), and confirmed assembleRelease itself builds. Deliberately did not enable R8/ProGuard minification: every data/*Api.kt class uses Gson with TypeToken<List<T>> generic reflection, which R8 can silently break without correct keep rules, and the only way to catch that here is exercising the authenticated, JSON-parsing-heavy screens on a minified build — exactly what login being unreachable prevents verifying.
• Files changed: feature/codebrowser/CodeBrowserViewModel.kt, feature/codebrowser/CodeBrowserViewModelTest.kt, tasks/016-release-hardening.md.
• Checks and results: assembleDebug testDebugUnitTest lintDebug --rerun-tasks BUILD SUCCESSFUL — 182 unit tests across 30 suites, 0 failures/errors, 0 lint errors; assembleRelease BUILD SUCCESSFUL (lintVitalRelease passed); full-repository secret-pattern scan clean (only the pre-existing test asserting client_secret absence); git diff --check clean.
• Review findings and resolutions: None beyond the P3 fix itself, which was already a recorded, pre-existing finding from an earlier review, not discovered fresh in this pass.
• Known limitations (both recorded as explicitly blocked acceptance criteria, not silently skipped): (1) R8/ProGuard minification was not enabled — left as an open decision for whoever has real device + login access to verify safely. (2) On-device regression of every authenticated screen built this session (repository list/favorites/organizations, code browser, history, work items, notifications, navigation back-stack, logout) could not be performed — structurally blocked on this agent never entering a password, confirmed with the human product owner rather than assumed.
• Next recommended task: This closes the originally-proposed roadmap (TASK-007 through TASK-016). Remaining work is exactly the two blocked items above, both requiring a human (or an agent with real login access) at a real device: complete the authenticated-screen regression pass, then make an informed call on enabling minification with real verification against a build that has actually exercised the JSON-heavy screens.
• Next owner: Human product owner or Codex, for the device-and-login-dependent items above; otherwise no further roadmap items remain unassigned.

2026-08-26 — TASK-019 OAuth callback crash recovery

• Agent and role: Codex, incident resolver; Claude diagnostic changes preserved.
• Commit/diff: working diff on claude/task-015-notifications pending commit.
• Features implemented: Restored the production OAuth request to its previously device-verified read-only scopes; added safe callback exception recovery, non-secret debug reason tags, and defensive saved-route decoding.
• How it was implemented: write:user is no longer part of UBGiteaOAuthDefaults; callback storage/validation failures are caught at the ViewModel coroutine boundary and become INVALID_CALLBACK; malformed or truncated route records are discarded and fall back to Repositories.
• Checks and results: Focused OAuth/repository/navigation tests passed; debug build, 184 unit tests across 30 suites, and lint passed; diff and focused secret checks passed.
• Review findings and resolutions: P1 target-server authorization incompatibility from TASK-018 scope expansion was resolved by suspending write scope. P1 repeat-launch crash risk from unchecked saved-route indexes was fixed with shape validation. Callback exception regression coverage was added.
• Known limitations: Physical-device callback verification is still required. Gitea star/unstar mutation is intentionally unavailable with the restored read-only token.
• Next recommended task: Install the rebuilt debug APK, clear UBGitea app data once, complete login approval, and verify repository loading.
• Next owner: Human product owner for device verification, then Claude for review.

2026-08-26 — TASK-020 repository-list crash fix

• Agent and role: Codex, incident resolver.
• Root cause: The repository LazyColumn used RepositoryCoordinates as its item key. Compose passes lazy-item keys to Android saved state, but this domain object is not a Bundle-saveable type, causing an uncaught main-thread IllegalArgumentException as soon as authenticated rows rendered.
• Implementation: Repository rows now use the stable string key owner/name; repository components cannot contain /, so the key remains unique across owners and repositories while being Android-saveable.
• Regression coverage: Added tests for deterministic key encoding and for equal repository names under different owners.
• Checks: Focused tests and assembleDebug testDebugUnitTest lintDebug passed. The APK installed wirelessly over the authenticated device, MainActivity remained resumed, and the cleared crash buffer stayed empty. Final visual inspection is pending because the handset locked.

2026-08-26 — TASK-021 global recent-update repository order

• Agent and role: Codex, implementer and device verifier.
• Root cause: This Gitea server returned /user/repos in apparent name order despite the existing sort=updated&order=desc query, so trusting server paging could not guarantee that the newest repository appeared on page 1.
• Implementation: The ViewModel now loads all server pages in 50-row batches, performs one stable descending sort by RepositorySummary.updatedAtEpochMillis, and slices that immutable snapshot into five-row UI pages. Snapshots are scoped by all/favorites/organization selection, reused for next/previous navigation, and invalidated by refresh and logout.
• Checks: Focused regression tests and assembleDebug testDebugUnitTest lintDebug passed. The rebuilt APK was installed wirelessly; the authenticated first page visibly changed from alphabetical order to recent-update order, all five rows loaded their latest branch labels, and the crash buffer remained empty.

2026-08-26 — TASK-022: tolerate incomplete Gitea branch timestamps

• Agent and role: Claude, picked up Codex's paused in-progress work in the same worktree (task-015-notifications) after the human product owner explicitly confirmed it was safe to continue rather than assuming so.
• Commit/diff: continued on claude/task-015-notifications; domain/model/RepositoryModels.kt, data/repositories/GiteaRepositoryBrowserApi.kt, feature/repositories/RepositoryListViewModel.kt and three test files.
• Features implemented: A repository with a branch whose commit timestamp is missing or malformed no longer fails the whole branch page (row-level latest-branch fetch or the repository reference screen). Root cause (per Codex's incident evidence, repo CSOT-T8-iPTN-AMA): listBranches's mapper required every commit.timestamp even though a timestamp isn't needed to identify or browse a branch.
• How it was implemented: Codex had already landed the core fix (BranchSummary.commitAtEpochMillis → nullable, mapper tolerates a missing/malformed value instead of throwing, latest-branch picker filters to non-null timestamps before taking the max) plus two of the needed tests, uncommitted, when this was picked up. Verified RepositoryReferencePresenter needed no change (it never reads the timestamp field) and added an explicit test proving that rather than leaving it implicit. Found and filled one real gap in the in-progress test coverage: a repository whose branches are all missing timestamps wasn't tested — confirmed the existing code already handles it correctly (reports LastPushedBranchUiState.Failed, distinct from Empty, rather than silently showing nothing) and added the missing test.
• Files changed: domain/model/RepositoryModels.kt, data/repositories/GiteaRepositoryBrowserApi.kt, feature/repositories/RepositoryListViewModel.kt, data/repositories/GiteaRepositoryBrowserApiTest.kt, feature/repositories/RepositoryReferencePresenterTest.kt, feature/repositories/RepositoryListViewModelTest.kt, tasks/022-tolerate-branch-timestamp-gaps.md.
• Checks and results: assembleDebug testDebugUnitTest lintDebug --rerun-tasks BUILD SUCCESSFUL, all unit tests passing, 0 lint errors; git diff --check clean; secret-pattern scan of the staged diff clean.
• Review findings and resolutions: One gap found and fixed in Codex's in-progress test coverage (the all-unknown-timestamps case) — see above.
• Known limitations: Not retested live against CSOT-T8-iPTN-AMA (or any repository with a real missing/malformed branch timestamp) on a physical device with this exact fix — Codex reproduced and diagnosed the original crash on-device, but this fix itself has only unit-test coverage so far.
• Next recommended task: A physical-device retest of this fix (Codex has working wireless-adb device access per TASK-020/021's evidence). No other roadmap items are open.
• Next owner: Codex or the human product owner, for the device retest; otherwise no further items are unassigned.

2026-08-26 — TASK-023: tolerate a literal JSON null list response

• Agent and role: Claude, live incident diagnosis and fix, with the human product owner's own device as the reporting/verification device (their first real end-to-end use of the app this session).
• Commit/diff: continued on claude/task-015-notifications; data/repositories/GiteaRepositoryBrowserApi.kt, data/repositories/GiteaRepositoryBrowserApiTest.kt.
• Features implemented: A parseList-backed endpoint (branches, tags, commits, repository listing) whose response body is the literal JSON null — Go's encoding/json serializes a nil slice this way instead of [] — now maps to an empty list instead of throwing ApiFailure.InvalidResponse(). Previously this showed a misleading "Gitea 서버에서 오류가 발생했습니다" (server error) message on a completely successful 200 OK response.
• How it was diagnosed: The human product owner set up wireless adb debugging to their own physical device this session (paired via adb pair/adb connect); this was used to install successive debug builds directly and read logcat live rather than round-tripping screenshots. First confirmed via the Gitea server's own Container Manager request log that the failing branches call was a genuine 200 OK in ~7ms, ruling out an actual server-side 5xx despite the app's own error message claiming one. Then added three rounds of temporary BuildConfig.DEBUG-gated Log.e diagnostics (the caught exception, per-item mapping detail, then the raw response body) to narrow the cause down to bodyPreview=null — a literal null string, not empty or malformed JSON. All diagnostic logging was removed before committing; only the real fix and a matching test remain.
• Files changed: data/repositories/GiteaRepositoryBrowserApi.kt, data/repositories/GiteaRepositoryBrowserApiTest.kt, tasks/023-tolerate-null-list-responses.md.
• Checks and results: assembleDebug testDebugUnitTest lintDebug --rerun-tasks BUILD SUCCESSFUL, all unit tests passing, 0 lint errors; git diff --check clean; secret-pattern scan clean. Verified live: reinstalled over wireless adb and the human product owner confirmed CSOT-T8-iPTN-AMA now opens correctly.
• Review findings and resolutions: The fix was made at the shared parseList helper level, not narrowly in listBranches, since the same Go nil-slice-to-null serialization can equally affect tags, commits, or repository listing — narrowing it to only the reported endpoint would have left the same latent bug in every sibling endpoint.
• Known limitations: CSOT-T8-MACRO_SA (the other repository that showed the same symptom) was not individually re-confirmed by the human product owner, though it goes through the identical code path.
• Next recommended task: None outstanding on the proposed roadmap. TASK-016's two previously-blocked items (full authenticated-screen device regression, R8/ProGuard minification decision) are now more tractable, since a real device session with working wireless adb and the human product owner's active participation is established for the first time this session.
• Next owner: Claude, continuing per the standing direction, or the human product owner if they'd rather drive further device testing directly.

2026-08-27 — TASK-024: history screen redesign (branch tap, colored selection, commit time, file diff, Z-Fold split view, compare removal)

• Agent and role: Claude, implementing a connected series of live, iterative requests from the human product owner while they tested the app in real time on their own Galaxy Z Fold over the wireless adb connection paired in the previous session.
• Commit/diff: continued on claude/task-015-notifications; see tasks/024-branch-tap-opens-history.md for the full file list — spans feature/repositories/, feature/history/, data/history/, domain/history/ (new UnifiedDiffParser.kt), domain/model/RepositoryModels.kt, ui/DateTimeFormatting.kt (new), and MainActivity.kt.
• Features implemented, in the order requested live: (1) tapping a branch/tag opens commit history instead of the file browser; (2) the selected reference row is color-coded instead of a "선택됨" text label; (3) branch/tag rows and commit rows show commit date/time with an explicit time zone; (4) tapping a changed file shows a parsed before/after diff (no extra network call — parsed client-side from the already-fetched combined patch); (5) the two diff panels scroll vertically in sync and share one horizontal scroll position; (6) diff lines are colored by text only (red/green), not background; (7) on a ≥600dp-wide screen (covers a Z Fold's inner screen unfolded) the file list and selected diff show side by side instead of the diff replacing the list; (8) the entire branch/tag compare feature was removed at the human product owner's request, since it wasn't going to be used.
• How it was implemented: Folded file-diff selection into CommitDetailContent as an in-place field (selectedFile: SelectedFileDiff?) rather than a separate navigational state, specifically so the wide-layout split view could show the list and the diff from one piece of state without duplicating any fetch logic. Along the way, found and fixed two real bugs via live device debugging: getCommitDetail was requesting /repos/{o}/{r}/commits/{sha} instead of /repos/{o}/{r}/git/commits/{sha} (the same path family the already-working .diff endpoint uses), which had been causing every commit tap to 404 with "커밋이나 기준을 찾을 수 없습니다" — found by checking the Gitea container's own request log first (ruling out a real server error) then bisecting with temporary debug-only logging. Separately, a horizontal-scroll bug reported live ("글자 한줄만 스크롤 되게 하지 말고") was fixed by replacing each diff line's independent rememberScrollState() with one shared ScrollState per panel.
• Files changed: see tasks/024-branch-tap-opens-history.md's Scope section for the full list (13 modified files, 4 new files, 1 new test directory).
• Checks and results: assembleDebug testDebugUnitTest lintDebug --rerun-tasks BUILD SUCCESSFUL at every checkpoint through this work (verified repeatedly, not just once at the end), most recently after the compare removal — all unit tests passing, 0 lint errors. git diff --check and secret-pattern scan clean.
• Review findings and resolutions: None from a separate review pass — self-review happened continuously via live device testing throughout, which is how items 5 and 8's underlying bugs (commit-detail 404, single-line horizontal scroll) were actually caught, rather than found afterward.
• Known limitations: File browsing (Route.CodeBrowser) is now unreachable from the UI — the reference screen was its only entry point, and item 1 redirected that tap to history instead. This is disclosed in the task file as a known, explicit side effect, not an oversight; a follow-up task (requested live, not yet started) will reintroduce it as a "Files" tab alongside "History" on the branch/tag detail screen. One live-reported rendering glitch (two screens appearing to overlap momentarily) has not been independently reproduced or root-caused. A final, single closing device-confirmation pass covering every item above together has not yet been explicitly requested and received.
• Next recommended task: Several more live requests are already queued from the same testing session: a tabbed Files/History branch-detail screen (bringing Route.CodeBrowser back into reach), an image-file viewer in the code browser, numbered pagination with direct page-entry for the Issues/PR list (repository/history/notification lists keep prev/next, since Gitea doesn't provide a total count for those endpoints), swipeable 전체/즐겨찾기 tabs on the repository list, and showing each repository row's last-commit time.
• Next owner: Claude, continuing through the queued live requests above.

2026-08-27 — TASK-025: tabbed branch detail screen, repository commit time, swipeable repo/favorites tabs, and six live-testing follow-up fixes

• Agent and role: Claude, continuing the same live testing session, implementing the previously-queued Files/History tab request plus a further rapid sequence of live requests and bug reports from the human product owner while they kept testing on their own Galaxy Z Fold over wireless adb.
• Commit/diff: continued on claude/task-015-notifications; see tasks/025-branch-detail-tabs.md for the full file list. Route.CodeBrowser/Route.History replaced by one Route.BranchDetail; new feature/branchdetail/BranchDetailScreen.kt and strings_branchdetail.xml; touch-ups across feature/history/HistoryScreen.kt, feature/codebrowser/CodeBrowserScreen.kt, feature/notifications/NotificationsScreen.kt, feature/workitems/WorkItemsScreen.kt, feature/repositories/RepositoryListScreen.kt, and their string resources.
• Features implemented: (1) tapping a branch/tag now opens one screen with two swipeable tabs, 파일 (Files, the restored TASK-006 code browser) and 히스토리 (History), instead of jumping straight to history as TASK-024 left it; (2) each repository row shows its last-commit time, reusing the existing updatedAtEpochMillis field; (3) the repository list's 전체/즐겨찾기 tabs are now swipeable, not just tap-to-switch; (4) fixed a live-reported overlapping-screen rendering bug in the commit-detail narrow layout (root cause: a BoxWithConstraints branch had multiple children as bare siblings instead of wrapped in a Column, so they stacked like Box children instead of arranging vertically); (5) fixed BranchDetailScreen's tab row rendering jammed against the status bar (it was the only top-level screen without its own Scaffold or explicit inset padding); (6) fixed horizontal scroll not working in the diff view (fillMaxWidth() before horizontalScroll() plus missing softWrap = false meant lines wrapped instead of overflowing); (7) simplified the references-loading message to a plain "로딩 중"; (8) removed every in-app screen-header back button in favor of the system back gesture already wired via each screen's BackHandler, including deleting WorkItemsScreen's back-button-only DetailHeader composable entirely; (9) replaced manual "새로고침" buttons on the repository and references lists with PullToRefreshBox pull-to-refresh.
• How it was implemented: Item 1's BranchDetailScreen wraps the existing CodeBrowserScreen/HistoryScreen unmodified in a TabRow + HorizontalPager, sharing one exit point (onCodeBrowserBack/onHistoryBack both close both ViewModels and pop the route) so their own internal BackHandlers never need extra coordination. Items 4-6 were each diagnosed from a live bug report (two of them via screenshot) rather than found proactively — item 4 specifically required disproving an initial wrong hypothesis (an adb force-stop/restart rendering artifact) after the human product owner reproduced it a second time following a clean manual relaunch, then confirming via adb shell dumpsys activity that only one window existed before looking at the Compose layout code itself. Item 9 hit a compile error (PullToRefreshBox is a Material3 experimental API) resolved by adding @OptIn(ExperimentalMaterial3Api::class) to both composables that use it.
• Files changed: see tasks/025-branch-detail-tabs.md's Scope section for the full list.
• Checks and results: ./gradlew compileDebugKotlin BUILD SUCCESSFUL (confirming the PullToRefreshBox OptIn fix); ./gradlew assembleDebug testDebugUnitTest lintDebug --rerun-tasks BUILD SUCCESSFUL in 3m 22s, 53 actionable tasks executed, all unit tests passing, 0 lint errors. Build installed on the human product owner's device over wireless adb.
• Review findings and resolutions: None from a separate review pass yet — self-review happened via live device testing, which is how items 4 and 6's underlying bugs were actually caught. The repositories_back string was deliberately kept (not removed alongside the other *_back strings) since it's a distinct error-state recovery action, not a header back button.
• Known limitations: Full device confirmation of this whole batch together (tabs, swipe, overlap fix, status-bar padding, diff scroll, back-button removal, pull-to-refresh) in one pass is still pending as of this commit — the individual fixes were each verified against their own specific report, but not yet re-confirmed together. Two items from the queued list are still not started: an image-file viewer in the code browser, and numbered pagination with direct page-entry for the Issues/PR list.
• Next recommended task: Get the human product owner's live confirmation of this batch, then pick up the two remaining queued items (image viewer, Issues/PR numbered pagination).
• Next owner: Claude, continuing per the standing direction.

2026-08-27 — TASK-025 follow-up: fix diff-view horizontal-scroll jitter

• Agent and role: Claude, same live testing session, responding to a screenshot-reported bug immediately after the TASK-025 batch above was installed.
• Commit/diff: continued on claude/task-015-notifications; feature/history/HistoryScreen.kt only.
• Bug: after TASK-025's first diff-scroll fix (removing fillMaxWidth(), adding softWrap = false), the human product owner reported that scrolling the diff view no longer failed to scroll, but instead made the text visibly jitter/snap ("코드에서 스크롤하니까 좌우 스크롤이 되는게 아니라 무슨 글자가 춤을 추네" — "the letters are dancing"), shown via screenshot.
• Root cause: DiffSideLine had every row in both diff panels sharing one ScrollState via Modifier.horizontalScroll(state). A ScrollState's max-scroll bound is set from whichever composable using it was most recently measured; with many rows of different line lengths in the same LazyColumn, each row's own layout pass overwrote that shared bound with its own (usually shorter or longer) width, so as different rows got remeasured during scrolling the bound — and therefore the effective clamp on the current scroll position — kept changing out from under the drag, snapping the visible text back and forth.
• Fix: replaced the shared ScrollState with a hand-driven offset: a single MutableFloatState updated by rememberScrollableState { delta -> ... } and clamped against one bound computed once per selected file (via rememberTextMeasurer(), measuring the longest line's character count against the diff's monospace style) instead of recomputed per row on every layout pass. Each row now uses Modifier.scrollable(...) purely for gesture capture and a plain Modifier.offset { ... } for rendering, wrapped in Box(Modifier.fillMaxWidth().clipToBounds()) since manual offset — unlike horizontalScroll — doesn't clip overflow by itself.
• Files changed: feature/history/HistoryScreen.kt, tasks/025-branch-detail-tabs.md (evidence updated in place rather than as a new task file, since this is a direct continuation of that task's item 6).
• Checks and results: ./gradlew compileDebugKotlin BUILD SUCCESSFUL; ./gradlew assembleDebug testDebugUnitTest lintDebug BUILD SUCCESSFUL, all unit tests passing, 0 lint errors. Reinstalled on the human product owner's device over wireless adb.
• Review findings and resolutions: None from a separate review pass — self-diagnosed from the live bug report and Compose's documented ScrollState/layout-bound semantics.
• Known limitations: The upper scroll bound is measured once per file (via a repeated single-character string of the longest line's length), not re-measured if the panel is resized mid-session (e.g., device rotation) — not expected to matter in practice since a file's selected diff is re-entered fresh on any real layout change, but noted for completeness. Live confirmation of this specific fix (does the jitter actually stop) is pending as of this commit, same as the rest of the TASK-025 batch.
• Next recommended task: Get the human product owner's live confirmation of the diff view specifically (in addition to the rest of the TASK-025 batch), then continue to the two remaining queued items.
• Next owner: Claude, continuing per the standing direction.

2026-08-27 — TASK-026: run OAuth login/consent in a Custom Tab instead of the external browser

• Agent and role: Claude, same live testing session, responding to a direct request after the human product owner re-paired their device over wireless adb under a fresh pairing code (the previous session's pairing had expired).
• Commit/diff: continued on claude/task-015-notifications; MainActivity.kt, app/build.gradle.kts, gradle/libs.versions.toml, tasks/026-oauth-custom-tabs.md.
• Feature implemented: tapping login previously opened the OAuth authorization URL via a plain Intent.ACTION_VIEW, switching fully away to a separate browser app for both the Gitea login form and the "Authorize this application" consent screen, then handing control back to UBGitea via the existing redirect-URI intent filter. It now opens in a Chrome Custom Tab (androidx.browser.customtabs.CustomTabsIntent) instead, which overlays the calling activity's own task rather than switching to a separate browser app/task — visually stays "in the app" through login and redirect back.
• How it was implemented: added the androidx.browser:browser dependency (new to this project) and swapped openSystemBrowser's plain Intent.ACTION_VIEW for CustomTabsIntent.Builder().build().launchUrl(...), renaming the method to openAuthorizationTab to match what it now does; the ActivityNotFoundException → viewModel.browserLaunchFailed() fallback was preserved unchanged. Deliberately did not implement this with an in-app WebView loading the login form directly — RFC 8252 prohibits embedded user-agents for OAuth precisely because a host-app-controlled WebView can read the login form's credentials as they're typed; Custom Tabs give the requested "stays in the app" feel without that risk, since the actual system browser (with its own isolated process, cookies, and saved passwords) still renders the page. No existing OAuth protocol code (OAuthAuthorizationRequest, OAuthCallbackValidator, Pkce, OAuthClientConfig, the manifest's redirect-URI intent filter) needed any change — Custom Tabs resolve the same ACTION_VIEW redirect a full external browser would.
• Files changed: MainActivity.kt, app/build.gradle.kts, gradle/libs.versions.toml, tasks/026-oauth-custom-tabs.md.
• Checks and results: ./gradlew compileDebugKotlin BUILD SUCCESSFUL; ./gradlew assembleDebug testDebugUnitTest lintDebug BUILD SUCCESSFUL in 3m 28s, 53 actionable tasks, all unit tests passing, 0 lint errors. Installed on the human product owner's device over wireless adb after re-pairing.
• Review findings and resolutions: None from a separate review pass — the WebView-vs-Custom-Tabs security tradeoff was reasoned through directly against RFC 8252 rather than found as a defect afterward.
• Known limitations: The Custom Tab's toolbar isn't tinted to match the app's own color scheme (left plain rather than hardcoding a color inconsistent with the app's dynamic/Material You theming) — a minor visual polish item, not a functional gap. The OAuth consent ("Authorize") click itself is unchanged and unavoidable by design; only the surface it renders on changed. Live end-to-end confirmation of the login flow is pending as of this commit.
• Next recommended task: Get the human product owner's live confirmation of the login flow, then continue to the two remaining queued items from TASK-024/025 (image viewer, Issues/PR numbered pagination).
• Next owner: Claude, continuing per the standing direction.

2026-08-27 — TASK-025 follow-up: fix diff-view horizontal-scroll direction

• Agent and role: Claude, self-directed device testing — the human product owner re-paired their device over wireless adb under a fresh pairing code/port and asked to test horizontal scroll on the current screen directly, rather than reporting a specific symptom first.
• Commit/diff: continued on claude/task-015-notifications; feature/history/HistoryScreen.kt only.
• Bug: verified by scripting adb shell input swipe in both directions against the live device and comparing before/after screenshots (rather than waiting for the human product owner to notice and describe it): the diff view's horizontal scroll, jitter-free since the previous follow-up, ran backwards — dragging left revealed the very start of the line (the -/+ prefix) instead of further content along it, and dragging right did the opposite. Every other horizontally-scrollable surface on Android does the reverse (drag left reveals more content to the right, i.e. "forward").
• Root cause: the manually-driven scroll offset from the previous follow-up computed newOffset = horizontalOffsetPx + delta inside rememberScrollableState { delta -> ... }; the sign was backwards for how Compose's scrollable reports delta for this gesture.
• Fix: flipped to newOffset = horizontalOffsetPx - delta (with the returned consumed-delta value adjusted to match). Reverified with the same scripted-swipe-plus-screenshot method: dragging left now reveals later content, dragging right returns toward the start, and both diff panels stay in sync throughout.
• Files changed: feature/history/HistoryScreen.kt, tasks/025-branch-detail-tabs.md (evidence updated in place, same as the prior diff-scroll follow-up).
• Checks and results: ./gradlew assembleDebug testDebugUnitTest lintDebug BUILD SUCCESSFUL, all unit tests passing, 0 lint errors. Reinstalled on the human product owner's device over wireless adb; the direction fix itself was verified directly via scripted swipes rather than waiting on a live report.
• Review findings and resolutions: None from a separate review pass — found via direct device testing prompted by the human product owner's "좌우 스크롤 해서 이상한걸 감지해볼래?" request, rather than a bug report.
• Known limitations: While investigating, also confirmed that partial characters get visually clipped at the viewport edge when scrolled to a non-character-aligned pixel position — this is expected behavior for any horizontally-scrolled monospace text (the same happens in GitHub's and VS Code's own diff/code viewers) and was not treated as a defect, though it was more noticeable while the direction bug was still live and scroll landed at unusual positions.
• Next recommended task: Get the human product owner's live confirmation of the diff view (jitter-free and now correctly directional) alongside the rest of the TASK-025 batch and the TASK-026 Custom Tabs login flow, then continue to the two remaining queued items (image viewer, Issues/PR numbered pagination).
• Next owner: Claude, continuing per the standing direction.

2026-08-27 — TASK-025 follow-up: fix tab-swipe vs. code-scroll gesture conflict

• Agent and role: Claude, live device testing continued directly from the direction-fix follow-up above; this time the human product owner watched the same swipe testing and reported "이거 왤케 떨리냐 화면이...?" (why is the screen trembling so much), then, after Claude's own scripted-swipe screenshots didn't reproduce anything conclusive, correctly root-caused it themselves: "저거 히스토리랑 파일 좌우 탭전환 기능이랑 코드 좌우 스크롤 기능이 섞이면서 그런 것 같은데" (the History/Files tab-swipe and the code's own left/right scroll are colliding).
• Commit/diff: continued on claude/task-015-notifications; feature/branchdetail/BranchDetailScreen.kt only.
• Bug: BranchDetailScreen's HorizontalPager (Files/History tab-swipe) and the diff view's own horizontal code scroll (from the two prior follow-ups) are both horizontal gestures layered on the same screen. Nested, they both tried to consume the same drag — visible as jittery/trembling scrolling, and separately (per a second report in the same message) as source text sometimes scrolling out of view entirely while viewing code.
• Fix: the human product owner specified the exact intended boundary directly — disable tab-swiping only while actual source code is on screen (a file's contents on the Files tab, or a selected file's diff on the History tab), keep it enabled everywhere else (folder listings, the commit list, a commit's changed-file list). Implemented as HorizontalPager(userScrollEnabled = !currentPageShowsScrollableCode, ...), where currentPageShowsScrollableCode reads the already-available codeBrowserState/historyState (both were already being collected in MainActivity and passed into this screen, so no new state plumbing was needed) depending on which page is current. Tapping a tab directly still always works, since that path is animateScrollToPage, not a gesture.
• Files changed: feature/branchdetail/BranchDetailScreen.kt, tasks/025-branch-detail-tabs.md (evidence updated in place, same pattern as the two prior diff-scroll follow-ups).
• Checks and results: ./gradlew assembleDebug testDebugUnitTest lintDebug BUILD SUCCESSFUL, all unit tests passing, 0 lint errors. Reinstalled on the human product owner's device over wireless adb; verified directly via scripted adb shell input swipe in both directions on both the code view (tab-swipe correctly disabled, code scrolls cleanly) and the file-list view (tab-swipe correctly still works) — an initial version of this same verification looked like a regression (swiping didn't switch tabs on the list view either) until re-checked: that test had swiped in the direction of a page that doesn't exist (already at the last page), not evidence of a real bug.
• Review findings and resolutions: None from a separate review pass. Notably, the human product owner diagnosed the actual root cause directly from watching the live behavior, ahead of Claude's own investigation — Claude's scripted-swipe screenshot sampling (∼1s intervals) had already been established as too coarse to catch genuine per-frame jitter, so the human's direct observation was the deciding signal here, not device automation.
• Known limitations: Whether the trembling is now fully gone (as opposed to just less likely to occur) has not been separately re-confirmed live by the human product owner as of this commit — the scripted-swipe verification confirms the gesture-ownership conflict is structurally resolved (only one consumer is ever active at a time now), but a live human touch test is the only way to confirm the felt result.
• Next recommended task: Get the human product owner's live confirmation of the whole TASK-025 batch plus this fix and the TASK-026 Custom Tabs login flow, together in one pass, then continue to the two remaining queued items (image viewer, Issues/PR numbered pagination).
• Next owner: Claude, continuing per the standing direction.

2026-08-27 — TASK-027: image viewer with swipe gallery navigation, and CSV table viewer

• Agent and role: Claude, implementing two features requested together in one message: an image viewer (asked for immediately after the swipe-conflict fix above shipped) and, mid-implementation, a CSV-as-table viewer (asked for as a follow-on message while this task was already in progress).
• Commit/diff: continued on claude/task-015-notifications; feature/codebrowser/content/ContentClassification.kt, feature/codebrowser/content/SourceContentClassifier.kt, feature/codebrowser/CodeBrowserViewModel.kt, feature/codebrowser/CodeBrowserScreen.kt, feature/branchdetail/BranchDetailScreen.kt, MainActivity.kt, plus matching tests and tasks/027-image-and-csv-viewer.md.
• Features implemented: opening an image file (PNG/JPEG/GIF/BMP/WebP, detected by magic bytes not extension) now decodes and shows it, with left/right swipe moving to the previous/next image among the same folder's other images — explicitly required to never trigger the Files/History tab underneath it to change, per the human product owner's direct instruction ("탭 전환은 발생하면 안돼"). Opening a .csv file now shows a scrollable table (rows/columns, first row styled as a header) instead of raw comma-separated text.
• How it was implemented: image detection runs before the pre-existing NUL-byte-means-Binary check in SourceContentClassifier, since every one of these formats' bytes contain NULs and would otherwise always be caught as generic Binary first. The sibling-image gallery is built for free from the directory listing already fetched to reach the file (CodeBrowserViewModel.openEntry captures the current Directory state's image-extension file entries into the new File state's siblingImagePaths), rather than a second network round-trip. navigateImage(delta) looks up the current path's index in that list and loads the neighbor. The image swipe itself is a discrete drag-distance threshold (not a continuous scroll position, unlike the diff view), while the CSV table reuses the diff view's manually-driven shared-offset horizontal-scroll pattern verbatim for consistency, even though CSV's fixed-width cells mean the specific bound-thrashing bug that pattern exists to avoid couldn't actually occur here. The tab-swipe-vs-content-scroll gating fix from the previous follow-up was widened (not duplicated) to also cover Image and Csv content.
• Files changed: see tasks/027-image-and-csv-viewer.md's Scope section for the full list.
• Checks and results: ./gradlew compileDebugKotlin compileDebugUnitTestKotlin BUILD SUCCESSFUL; ./gradlew testDebugUnitTest BUILD SUCCESSFUL, all unit tests passing (new coverage: magic-byte detection for all five formats, an image signature's embedded NUL not short-circuiting to Binary, oversized-before-image-detection ordering, CSV path-extension gating, quoted-field/escaped-quote parsing, row-truncation, gallery capture in listing order excluding a non-image sibling, navigateImage moving and stopping at both ends, navigateImage no-op outside a directory listing); ./gradlew assembleDebug lintDebug BUILD SUCCESSFUL, 0 lint errors. Installed on the human product owner's device over wireless adb.
• Review findings and resolutions: None from a separate review pass.
• Known limitations: Not yet confirmed against a real image or CSV file on the live device — every repository browsed this session for a suitable test file (see TASK-028's log entry below for the same search, done for the same reason) didn't have one readily reachable. Relying on the unit test coverage above until a live file turns up. CSV column width is a fixed 120dp per cell, not sized to content.
• Next recommended task: Get live confirmation of both this and TASK-028 (or supply/point to a repo with an actual image/CSV file and some issues/PRs), otherwise continue per the standing direction.
• Next owner: Claude, continuing per the standing direction.

2026-08-27 — TASK-028: numbered, jump-to-page pagination for the Issues/PR list

• Agent and role: Claude, implementing the second half of the same combined request as TASK-027 above.
• Commit/diff: continued on claude/task-015-notifications; domain/model/RepositoryModels.kt, data/workitems/GiteaWorkItemsApi.kt, feature/workitems/WorkItemsViewModel.kt, feature/workitems/WorkItemsScreen.kt, MainActivity.kt, plus matching tests and tasks/028-issues-prs-numbered-pagination.md.
• Feature implemented: the Issues list and the PR list each now show up to 5 numbered page buttons (tap to jump directly), previous/next, and a [ page / total ]-style text field to type an exact page number and jump straight there — replacing plain previous/next-only, on this screen alone. Matches the earlier AskUserQuestion resolution from this session (apply numbered pagination only where a total count is knowable) — repository/history/notification lists are unchanged, still plain previous/next, since Gitea's endpoints for those don't report a total.
• How it was implemented: verified directly against Gitea's own source (routers/api/v1/repo/issue.go's swagger doc comment) that both the issue-list and pull-request-list endpoints report a total match count via X-Total-Count, and that a documented type=issues/type=pulls query parameter exists — rather than assume either. listIssues now sends type=issues so both the returned items and the total count exclude pull requests server-side (previously, filtering was client-side only, which the class doc comment had explicitly defended as deliberate — that reasoning was rewritten now that a verified server-side option exists). Page<T> gained an optional, defaulted totalCount, so none of the app's other 9+ Page.of(...) call sites needed to change. The numbered footer falls back to the original plain previous/next row whenever totalPages is null, rather than ever showing a broken or missing count.
• Files changed: see tasks/028-issues-prs-numbered-pagination.md's Scope section for the full list.
• Checks and results: ./gradlew compileDebugKotlin compileDebugUnitTestKotlin BUILD SUCCESSFUL; ./gradlew testDebugUnitTest BUILD SUCCESSFUL, all unit tests passing (new coverage: type=issues sent, X-Total-Count parsed for both issues and pull requests, absent header leaves totalCount null, a fractional total rounds up to the correct page count, goToPage jumps directly, Page.totalCount defaults/validates correctly); ./gradlew assembleDebug lintDebug BUILD SUCCESSFUL, 0 lint errors. Installed on the human product owner's device over wireless adb.
• Review findings and resolutions: None from a separate review pass.
• Known limitations: Checked the Issues and Pull Request tabs on four of the human product owner's actual repositories live; every one had zero issues and zero pull requests, so the numbered-pagination UI was never actually populated with real data this session — confirmed instead that the screen doesn't crash and correctly falls back to the existing empty state on all four. Relying on the unit test coverage above (header parsing, total-page-count math, jump behavior) until a repository with real issues/PRs is available to confirm the rendered UI itself.
• Next recommended task: Get live confirmation of both this and TASK-027 (or supply/point to a repository with real issues/PRs and an image/CSV file), otherwise continue per the standing direction — no other items remain on the queued list from this session.
• Next owner: Claude, continuing per the standing direction.

2026-08-27 — TASK-027 follow-up: pinch-to-zoom and pan for the image viewer

• Agent and role: Claude, direct continuation of the same live session — the human product owner confirmed the image opened correctly, then asked for zoom directly ("확대 축소 기능도 만들어줄래?").
• Commit/diff: continued on claude/task-015-notifications; feature/codebrowser/CodeBrowserScreen.kt only.
• Feature implemented: pinch-to-zoom (1x–5x) with pan while zoomed in, and double-tap to toggle between 1x and 2x — added to the image viewer from the earlier TASK-027 commit.
• How it was implemented: rather than stacking a separate zoom/pan gesture detector alongside the existing swipe-navigate one (which would have reintroduced exactly the class of bug TASK-025 hit twice — two independent pointerInput detectors both trying to consume the same single-finger drag), all three behaviors — pinch-zoom, pan-while-zoomed, and swipe-navigate — were combined into one hand-rolled awaitEachGesture loop that reads live pointer count each event and branches: 2+ pointers is always pinch-zoom/pan (calculateZoom/calculatePan); 1 pointer while already zoomed in pans; 1 pointer at 1x is reserved for the pre-existing swipe-navigate drag accumulator. A double-tap toggle was added via a second, non-competing pointerInput (detectTapGestures doesn't accumulate drag distance, so it doesn't fight the first block). Zoom/pan state is remember(content)-scoped so navigating to a different image in the gallery always starts that image at 1x rather than carrying over the previous image's zoom. Pan is clamped to an approximate (not pixel-exact) bound to keep a zoomed image roughly on screen.
• Files changed: feature/codebrowser/CodeBrowserScreen.kt, tasks/027-image-and-csv-viewer.md (evidence updated in place, matching the pattern used for TASK-025's own follow-ups).
• Checks and results: ./gradlew compileDebugKotlin BUILD SUCCESSFUL; ./gradlew assembleDebug testDebugUnitTest lintDebug BUILD SUCCESSFUL, all unit tests passing, 0 lint errors. Reinstalled on the human product owner's device over wireless adb.
• Review findings and resolutions: None from a separate review pass — the single-gesture-loop design was chosen proactively, reasoning directly from the two prior tab-swipe/content-scroll gesture conflicts this session had already found and fixed, rather than discovered as a defect afterward.
• Known limitations: The pinch-zoom/pan/double-tap gestures themselves haven't been live-confirmed yet (only that the image itself opens, from the prior install) — no dedicated unit test exists for this either, since it's pure Compose gesture-handling with no non-UI logic to isolate. The single-gesture-loop design structurally prevents the earlier bug class by construction, but that's a design argument pending an actual live touch test, not a substitute for one.
• Next recommended task: Get live confirmation of the zoom/pan/double-tap gestures specifically, plus the still-outstanding CSV table and Issues/PR numbered pagination confirmations from earlier today, otherwise continue per the standing direction.
• Next owner: Claude, continuing per the standing direction.

2026-08-27 — TASK-027 follow-up: PDF viewer

• Agent and role: Claude, direct continuation of the same live session — the human product owner tried opening a PDF file next and asked "pdf 파일은 못읽나?" (can't PDF files be read?).
• Commit/diff: continued on claude/task-015-notifications; feature/codebrowser/content/ContentClassification.kt, feature/codebrowser/content/SourceContentClassifier.kt, feature/codebrowser/CodeBrowserViewModel.kt, feature/codebrowser/CodeBrowserScreen.kt, feature/branchdetail/BranchDetailScreen.kt, plus a matching test and tasks/027-image-and-csv-viewer.md.
• Feature implemented: opening a .pdf file (detected by %PDF- magic bytes) now renders its pages, with the same left/right swipe-between-pages, pinch-zoom, pan, and double-tap-to-toggle-zoom interaction already built for the image viewer.
• How it was implemented: rendering uses Android's built-in android.graphics.pdf.PdfRenderer (API 21+, no compatibility concern against this app's minSdk = 28) — no new dependency, matching how the image viewer already used the platform's own BitmapFactory instead of a third-party decoding library. PdfRenderer only accepts a ParcelFileDescriptor backed by a real file, so the already-fetched bytes get written to a throwaway temp file purely to satisfy that, deleted in a finally block regardless of outcome; the file is fully re-opened and the requested page re-rendered on every page turn rather than keeping a PdfRenderer held open across recompositions, trading some redundant I/O for avoiding a class of lifecycle bug that's easy to introduce holding a stateful Android resource across Compose's recomposition lifecycle. The pinch-zoom/pan/swipe-navigate/double-tap gesture code from the prior pinch-zoom follow-up was extracted into a shared ZoomableSwipeableBox composable specifically so this viewer could reuse it verbatim rather than duplicating that fairly intricate gesture-arbitration logic a second time. Classification itself only detects "is this a PDF" by magic bytes — page count and rendering stay entirely in the UI layer (LaunchedEffect), the same split already used for images, keeping the classifier framework-agnostic and unit-testable without Robolectric. Separately, maxInputBytes was raised from 1MB to 10MB in CodeBrowserViewModel's classifier config — at 1MB, most real-world photos and PDFs would have been rejected as Oversized before ever being classified, which would have made both this feature and the image viewer close to useless in practice; 10MB is still a deliberately conservative mobile-safe ceiling, not "however large."
• Files changed: see tasks/027-image-and-csv-viewer.md's Scope section for the full list.
• Checks and results: ./gradlew compileDebugKotlin BUILD SUCCESSFUL; ./gradlew compileDebugUnitTestKotlin testDebugUnitTest BUILD SUCCESSFUL, all unit tests passing (new coverage: %PDF- signature detection, its embedded NUL bytes not short-circuiting to Binary, oversized-before-PDF-detection ordering, plain text starting with % not misclassified as PDF); ./gradlew assembleDebug lintDebug BUILD SUCCESSFUL, 0 lint errors. Installed on the human product owner's device over wireless adb.
• Review findings and resolutions: None from a separate review pass.
• Known limitations: Neither the PDF rendering path nor the shared gesture code has a dedicated unit test — both are Android-framework/pure-UI concerns with no non-UI logic to isolate (PdfRenderer specifically isn't available in a plain JVM unit test without Robolectric). Not yet confirmed against a real .pdf file on the live device — no repository browsed this session had one readily reachable, same as the still-outstanding CSV table confirmation. Re-opening and fully re-rendering the file on every page turn hasn't been performance-checked against a real large, many-page PDF.
• Next recommended task: Get live confirmation of the PDF viewer, the CSV table, pinch-zoom/pan/double-tap, and the Issues/PR numbered pagination — everything built this session that's still pending a live look — otherwise continue per the standing direction. No other items remain queued.
• Next owner: Claude, continuing per the standing direction.

2026-08-27 — TASK-029: OAuth refresh-token support

• Agent and role: Claude, responding directly to a live complaint — "그리고 애플리케이션 승인 안하고 로그인 쭉 이어서 되어있게 해주면 안되나?" (can't login just stay continuous without having to approve the application) — asked immediately after a separate feature request (push notifications for favorited repos, see feasibility note below) revealed why it mattered to the human product owner: reliable long-lived auth is a prerequisite for any kind of background checking.
• Commit/diff: continued on claude/task-015-notifications; data/auth/AuthApi.kt, new core/auth/android/RefreshingTokenProvider.kt and core/auth/android/AuthSession.kt, feature/repositories/RepositoryListViewModel.kt, and the Factory classes of all five ViewModels, plus matching tests and tasks/029-oauth-token-refresh.md.
• Bug found while investigating: the app already captured Gitea's OAuth refresh token on login (it was part of the persisted TokenSet) but never actually used it anywhere — RepositoryListViewModel.restoreSession() cleared the whole session and forced a brand-new browser-based login (Custom Tab open, Gitea login, "Authorize this application?" consent screen) the instant the access token's stated expiry passed, every single time, discarding a perfectly usable refresh token each time.
• How it was implemented: verified Gitea's actual refresh_token grant shape directly against its source (routers/web/auth/oauth2_provider.go's handleRefreshToken) before implementing, per this project's established convention, rather than assuming the standard OAuth2 shape applied unmodified. Added AuthenticationGateway.refreshToken (shares the existing exchangeCode response-parsing code) and a new RefreshingTokenProvider that proactively refreshes a token 60 seconds ahead of its stated expiry (not reactively after a failed call) — proactive specifically because the provider is now shared across all five features' independent API clients via a new AuthSession singleton, replacing what used to be five separately-constructed, mutually-unaware AndroidKeystoreTokenVault/BearerTokenProvider pairs; sharing means a refresh triggered by one feature's next call is immediately visible to every other feature too, and the provider's internal Mutex actually prevents concurrent refreshes only because every feature now goes through the same instance. RepositoryListViewModel.restoreSession()'s old "already past its stated expiry → clear and fail immediately" clock check was removed outright (not adjusted) since it fired before the now-refresh-capable API call ever got a chance to run — the exact same fallback behavior (clear + AUTHENTICATION_EXPIRED) still happens today, just driven by a real failed API call instead of a client-side guess made too early.
• Files changed: see tasks/029-oauth-token-refresh.md's Scope section for the full list.
• Checks and results: ./gradlew compileDebugKotlin compileDebugUnitTestKotlin BUILD SUCCESSFUL (after finding and fixing one missed loadRepositories(tokens) call site broken by the signature change); ./gradlew testDebugUnitTest BUILD SUCCESSFUL, all unit tests passing (after finding and fixing two bugs in the new tests' own fixture data — not the implementation — flagged by two initially-failing assertions); ./gradlew assembleDebug lintDebug BUILD SUCCESSFUL, 0 lint errors. Installed on the human product owner's device over wireless adb.
• Review findings and resolutions: None from a separate review pass.
• Known limitations: Proactive-refresh only — no "catch a live 401 and retry once" fallback at the transport layer (a token revoked server-side for a reason other than ordinary expiry still surfaces as a normal 401, correctly, just not silently retried). Not yet confirmed against a real long-idle session on the device — the fix targets a problem that only manifests after enough real time passes for a token to actually expire, and this session's live testing so far has been continuous active use rather than a multi-hour gap.
• Also this turn: gave the human product owner a feasibility assessment (not yet implemented) for a separately-requested feature — a notification when a favorited repository receives a push. Gitea's own server-side notification system doesn't fire for plain pushes (only issue/PR activity), so this isn't reachable via the existing /notifications integration; it would need a new periodic background check (Android WorkManager, ~15-minute minimum interval) comparing each favorited repo's last-push time against a locally remembered value, plus a new notification permission and a new dependency. Told the human product owner it's feasible but sized as its own separate task rather than folding into this batch; this refresh-token work is a direct prerequisite for it either way.
• Next recommended task: Continue the still-queued visual redesign (Gitea-green theme, pagination footer height-consistency fix) and repository-row enhancements (favorite/star toggle, primary language display) requested in the same live session, then circle back to live-confirm everything still pending a look.
• Next owner: Claude, continuing per the standing direction.

2026-08-27 — TASK-030: Gitea-green theme, pagination footer height fix, repository row language/favorite

• Agent and role: Claude, direct continuation of the same live session — the human product owner, after a status-summary check-in and approving the remaining queued image-viewer/pagination work, sent a screenshot of the real Gitea web UI and asked for a matching green theme ("Gitea 자체가 녹색의 찻잎 같은 분위기니까 그거에 맞게 디자인을 진행해줄 수 있어?"), with an explicit hard constraint that functionality and interaction feel must never change, plus a separately-reported bug: the pagination footer's button heights kept visibly changing. A mid-turn message in the same batch also asked for each repository row to show its favorite/star action and primary language.
• Commit/diff: continued on claude/task-015-notifications; new ui/theme/Color.kt, rewritten ui/theme/Theme.kt, new ui/PaginationFooter.kt, feature/history/HistoryScreen.kt, feature/notifications/NotificationsScreen.kt, feature/repositories/RepositoryListScreen.kt, feature/workitems/WorkItemsScreen.kt, domain/model/RepositoryModels.kt, data/repositories/GiteaRepositoryBrowserApi.kt, feature/repositories/RepositoryListViewModel.kt, MainActivity.kt, a new/updated test, and tasks/030-gitea-green-theme-and-repo-row-enhancements.md.
• Feature implemented: the whole app now uses a real Material3 color scheme built from Gitea's own brand green instead of Compose's unthemed default purple (the app's lightColorScheme()/darkColorScheme() had never been given explicit role values before now); every pagination footer's buttons now render at one guaranteed-consistent height; and each repository row now shows its Gitea-reported primary language plus a tappable star toggle wired to the favorite action.
• How it was implemented: verified Gitea's actual brand green (--color-logo: #609926) against Gitea's own source before picking a palette, per this project's established convention, then hand-built a full light+dark tonal palette from that hue — primary itself uses a deliberately deepened #3B6A1F rather than the raw logo color, since white text on #609926 sits under the WCAG 4.5:1 contrast threshold for buttons; error/diff-removed-line red was left untouched at Material3's baseline, since nothing about the request was about error coloring. The footer-height bug was fixed by extracting one shared SimplePaginationFooter used by all four screens' plain previous/next footers, plus pinning an explicit Modifier.height(PaginationButtonHeight) on every button in the work-items numbered footer (which had been mixing TextButton/OutlinedButton variants with an inconsistent custom contentPadding on the numbered buttons specifically) — an explicit height guarantees consistency by construction regardless of exactly which Material3 default/padding interaction was the literal cause. Language and star count needed no new network call, since Gitea's existing repository-list response already includes both fields (verified against Gitea's Repository struct); the star toggle reuses TASK-018's existing toggleFavorite action unmodified, with a new mode-aware FavoriteStar composable branching its rendering on whether the current list is ALL (tap stars) or FAVORITES (tap un-favorites and removes the row).
• Files changed: see tasks/030-gitea-green-theme-and-repo-row-enhancements.md's Scope section for the full list.
• Checks and results: ./gradlew compileDebugKotlin compileDebugUnitTestKotlin BUILD SUCCESSFUL; ./gradlew testDebugUnitTest BUILD SUCCESSFUL, all unit tests passing (new coverage: repository language/star-count mapping, blank language becoming null); ./gradlew assembleDebug lintDebug BUILD SUCCESSFUL, 0 lint errors. Installed on the human product owner's device over wireless adb; screenshots taken directly on the device confirm the green theme applied consistently, matching footer button heights, and language/star display on repository rows.
• Review findings and resolutions: None from a separate review pass.
• Known limitations: a repository already starred before the current app session still shows an outlined (not filled) star until acted on this session — carried over unchanged from TASK-018's original design. No per-language color coding (no reliable local source for GitHub/Gitea's linguist color mapping) — language is shown as plain text. The hand-built palette's contrast was reasoned through directly for the primary/onPrimary pairing specifically, not verified with an automated contrast checker across every color role. Full live human confirmation of this batch is still pending, even though device screenshots taken this session already show all three pieces working correctly.
• Next recommended task: Get live confirmation from the human product owner of everything still pending a look this session — pinch-zoom/pan on images, the CSV table viewer, the PDF viewer, Issues/PR numbered pagination, and now this theme/footer/star-language batch — then, if wanted, size and build the previously-scoped push-notification-on-favorited-repo-push feature as its own task.
• Next owner: Claude, continuing per the standing direction.

2026-08-27 — TASK-031: "커밋" label rename, EUC-KR decode fallback, HTTP timeout/connection-pooling fix

• Agent and role: Claude, direct continuation of the same live session. Three separate live bug reports arrived while TASK-030 was being finished up: after confirming the "History" tab/screen was in fact the commit history, the human product owner asked for the label itself to say "커밋" instead; separately, "지금 .cpp, .h 파일은 잘 못읽는 것 같다 자꾸 UTF-8로 안전하게 읽을 수 없는 파일이래" (.cpp/.h files keep failing to open, saying they can't be safely read as UTF-8) plus "파일 양이 많아지면 불러오는데 너무 오래 걸려" (loading takes too long once there are a lot of files); and, while investigating those, a further live report — "LGD-P9-CLCI-4K는 커밋 이력을 보려고 하면 서버에 연결할 수 없습니다... 이거 이전에도 비슷한거 그랬었지 않았나?" (that repository's commit history says it can't reach the server — didn't something similar happen before?) — which traced back to the same underlying cause as the "too slow" complaint.
• Commit/diff: continued on claude/task-015-notifications; strings_branchdetail.xml, strings_codebrowser.xml, strings_history.xml, feature/codebrowser/content/SourceContentClassifier.kt (+ test), core/network/HttpTransport.kt, plus tasks/031-commit-label-euckr-fallback-http-timeouts.md.
• Feature/fixes implemented: (1) every user-facing "히스토리" label became "커밋" (a full res/values scan found exactly three occurrences: the branch-detail tab, the code-browser's history button, and one sentence in a permission-denied message); (2) the content classifier now tries EUC-KR (strictly, same as its existing UTF-8 attempt) before giving up, so legacy Korean-encoded C/C++ source files render instead of failing as UnsupportedEncoding; (3) OkHttpTransport's default client changed from a fresh, unconfigured OkHttpClient() per call site to one shared client with longer timeouts (15s connect / 30s read / 15s write, versus the previous unconfigured 10s/10s/10s).
• Bug found while investigating: the "server unreachable" error on a large repository's commit history and the "loading takes too long" complaint traced back to the exact same root cause — every one of the app's ~8 OkHttpTransport() call sites built its own fresh, default-configured OkHttpClient(), whose 10-second timeouts were too tight for this app's actual Gitea host (a home Synology NAS, not a datacenter service); GiteaRepositoryBrowserApi.authenticated/GiteaHistoryApi.get both catch IOException broadly (which includes SocketTimeoutException) and wrap it as ApiFailure.Network, rendered identically to a genuinely offline device — a slow-but-working request on a large commit history or a directory with many entries was being cut off and misreported before it had a real chance to finish.
• How it was implemented: the EUC-KR fallback reuses the classifier's existing strict-decode discipline (CodingErrorAction.REPORT, never REPLACE) so a second well-defined charset is tried, not a permissive catch-all — a byte sequence invalid in both UTF-8 and EUC-KR still correctly falls through to UnsupportedEncoding. EUC-KR specifically, not the larger MS949/CP949 superset, because Android's own Charset documentation guarantees EUC-KR is bundled on every device via ICU while CP949 support isn't guaranteed — using CP949 risked passing this project's host-JVM unit tests while throwing UnsupportedCharsetException at runtime on the actual device. The HTTP fix is one shared, lazily-built OkHttpClient used as OkHttpTransport's new default, which both gives slow-but-working requests room to complete and lets every feature's calls to the same host reuse one connection pool (avoiding a fresh TCP/TLS handshake per feature) instead of each of the ~8 call sites opening its own.
• Files changed: see tasks/031-commit-label-euckr-fallback-http-timeouts.md's Scope section for the full list.
• Checks and results: ./gradlew compileDebugKotlin compileDebugUnitTestKotlin BUILD SUCCESSFUL; ./gradlew testDebugUnitTest BUILD SUCCESSFUL, all unit tests passing (new coverage: EUC-KR-encoded text classifies as Text; a byte sequence invalid in both UTF-8 and EUC-KR still classifies as UnsupportedEncoding; the two pre-existing "malformed UTF-8" tests were checked against EUC-KR's own lead/trail-byte rules to confirm they still exercise the "both attempts fail" path). ./gradlew assembleDebug lintDebug BUILD SUCCESSFUL, 0 lint errors. Installed on the human product owner's device over wireless adb.
• Review findings and resolutions: None from a separate review pass.
• Known limitations: the error message still doesn't distinguish "genuinely offline" from "reachable but slow" — a request still too slow even at 30 seconds, or a truly offline device, both still render the same message; the fix targets the common slow-NAS case specifically, not a full error-taxonomy redesign. EUC-KR only, not CP949's extended completion range (deliberate, see task file). No response caching was added — the connection-pool sharing cuts handshake overhead, not the request/response itself.
• Next recommended task: get live confirmation from the human product owner that "LGD-P9-CLCI-4K"'s commit history now loads, that .cpp/.h files open correctly, and that the "커밋" label reads right — not yet re-tested against those exact cases in this session. Also still pending from earlier in this session: the green theme/footer-height/language-star batch (TASK-030), pinch-zoom/pan, CSV, PDF, and Issues/PR numbered pagination.
• Next owner: Claude, continuing per the standing direction.

2026-08-27 — TASK-032: fix reversed ALL/FAVORITES swipe direction on the repository list

• Agent and role: Claude, direct continuation of the same live session — "메인 화면 좌우 탭전환 스와이프가 반대로 되어 있는 것 같다" (the main screen's left/right tab-switch swipe seems reversed).
• Commit/diff: continued on claude/task-015-notifications; feature/repositories/RepositoryListScreen.kt only, plus tasks/032-repository-list-swipe-direction-fix.md.
• Bug found: the repository list (the app's actual home screen after login, distinct from BranchDetailScreen's already-correct Files/Commit HorizontalPager) switches its ALL/FAVORITES tabs via a hand-rolled detectHorizontalDragGestures modifier rather than HorizontalPager, and that gesture's onDragEnd had its comparison signs backwards relative to the drag-follows-finger convention every other swipe surface in this app already uses: swiping right moved ALL -> FAVORITES and swiping left moved FAVORITES -> ALL, the opposite of what a rightward drag revealing the left-hand tab (and vice versa) should do.
• How it was implemented: the two when branch conditions in modeSwipeGesture's onDragEnd were swapped (comparison direction only — the drag-accumulation and threshold logic were untouched), confirmed correct by re-deriving the convention directly from BranchDetailScreen's already-correct HorizontalPager behavior and from ModeTabs's actual tab order (ALL left, FAVORITES right) rather than guessing.
• Files changed: feature/repositories/RepositoryListScreen.kt, tasks/032-repository-list-swipe-direction-fix.md.
• Checks and results: ./gradlew compileDebugKotlin compileDebugUnitTestKotlin BUILD SUCCESSFUL; ./gradlew testDebugUnitTest BUILD SUCCESSFUL, all unit tests passing (no dedicated test for this gesture, same category as this app's other pure-Compose gesture code); ./gradlew assembleDebug lintDebug BUILD SUCCESSFUL, 0 lint errors. Installed on the human product owner's device over wireless adb.
• Review findings and resolutions: None from a separate review pass.
• Known limitations: no dedicated unit test for the gesture direction itself; live confirmation of the corrected swipe feel is still pending in this session.
• Also this turn: while looking into a separately-reported bug (tapping a repository's new favorite star turns it red but doesn't actually favorite it), traced the root cause to a real architectural conflict rather than a simple bug — Gitea's PUT/DELETE /user/starred/{owner}/{repo} endpoints require write:repository OAuth scope (verified against Gitea's own route registration source), but this app's OAuthClientConfig has a hard require(scopes.all { it.isReadOnly }) invariant and only ever requests read-only scopes. Every star/unstar attempt is therefore guaranteed to fail server-side (403), caught generically, and rendered as the reported red "failed" star. Not fixed yet — this needs the human product owner's direction, since the only real fix (requesting write:repository) breaks the just-built persistent-login promise from TASK-029 at least once (a scope change requires fresh consent) and changes this app's deliberate read-only security posture; flagged to them rather than decided unilaterally.
• Next recommended task: get the human product owner's direction on the star/favorite OAuth-scope conflict (add write scope vs. make favorites a local-only bookmark vs. remove the feature), then continue per the standing direction — still pending from earlier in this session: TASK-030's green theme/footer-height/language-star batch, TASK-031's label/EUC-KR/timeout batch, pinch-zoom/pan, CSV, PDF, and Issues/PR numbered pagination, all awaiting live confirmation.
• Next owner: Claude, continuing per the standing direction once the human product owner responds on the OAuth-scope question.

2026-08-27 — TASK-033: request write:repository OAuth scope so starring actually works

• Agent and role: Claude, direct continuation of the same live session — following up on the star/unstar-always-fails root cause traced during TASK-032. Presented the human product owner with three options (add write:repository scope / make favorites a local-only bookmark / remove the feature); they chose to add the scope.
• Commit/diff: continued on claude/task-015-notifications; core/auth/protocol/OAuthClientConfig.kt and OAuthClientConfigTest.kt, plus tasks/033-write-repository-oauth-scope-for-starring.md.
• Feature implemented: write:repository is now requested alongside this app's existing read-only OAuth scopes, added as one narrow, explicit exception to the require(scopes.all { it.isReadOnly }) invariant rather than a blanket relaxation — every other write scope (including the pre-existing, still-unused WRITE_USER value) is still rejected, confirmed by a new test that pairs it with the now-allowed write:repository and checks it's still rejected.
• How it was implemented: verified directly against Gitea's own route registration source (routers/api/v1/api.go) that PUT/DELETE /user/starred/{owner}/{repo} require Write-level access within the repository scope category — read:repository alone can never satisfy it, so this wasn't fixable from the client side any other way. No change was needed to toggleFavorite, FavoriteStar, or any other favorite-feature code from TASK-018/TASK-030 — all of that was already correctly built against the RepositoryFavorites interface; the only thing wrong was the token it was being handed never had permission to actually star anything.
• Files changed: core/auth/protocol/OAuthClientConfig.kt, OAuthClientConfigTest.kt, tasks/033-write-repository-oauth-scope-for-starring.md.
• Checks and results: ./gradlew compileDebugKotlin compileDebugUnitTestKotlin BUILD SUCCESSFUL; ./gradlew testDebugUnitTest BUILD SUCCESSFUL, all unit tests passing (new coverage: write:repository alone is now accepted; write:user is still rejected even alongside the now-allowed write:repository; the pre-existing write-scope-rejection test is unaffected); ./gradlew assembleDebug lintDebug BUILD SUCCESSFUL, 0 lint errors. Installed on the human product owner's device over wireless adb.
• Review findings and resolutions: None from a separate review pass.
• Known limitations: a device already logged in under the old, read-only-only scope needs one explicit re-login before starring actually works — TASK-029's refresh-token flow keeps a session alive indefinitely for the scope it was originally granted, and a refresh doesn't expand that scope. This is expected and was reported directly to the human product owner rather than silently worked around (e.g. by force-clearing the stored session on their behalf), since that kind of forced logout should be their call. Live confirmation (star actually succeeding after a fresh login) is still pending.
• Next recommended task: ask the human product owner to log out and back in once, then confirm starring/unstarring actually works. Still pending from earlier in this session: TASK-030's green theme/footer-height/language-star batch, TASK-031's label/EUC-KR/timeout batch, TASK-032's swipe-direction fix, pinch-zoom/pan, CSV, PDF, and Issues/PR numbered pagination, all awaiting live confirmation.
• Next owner: Claude, continuing per the standing direction.

2026-08-27 — TASK-033 follow-up: diagnosed the "denied:server_error" login failure after the scope change

• Agent and role: Claude, direct continuation of the same live session — "로그인이 안돼" (login isn't working) after installing the write:repository build; device screenshot showed "로그인 응답을 확인할 수 없습니다... [debug] denied:server_error".
• Diagnosis, not a code change: verified the running Gitea instance is 1.23.5 (via /api/v1/version, confirmed a modern version with full scoped-OAuth-token support, ruling out a version gap). Reproduced the authorize request's own URL directly (dummy PKCE values, real client_id/redirect_uri/scope) in a browser to confirm it reaches Gitea's login page cleanly rather than erroring at the HTTP-parsing level. Then traced GrantApplicationOAuth in Gitea's own source (routers/web/auth/oauth2_provider.go, 1.23 branch) and found the exact check responsible: if grant.Scope != form.Scope { ...ErrorCode: ErrorCodeServerError, ErrorDescription: "a grant exists with different scope" } — Gitea deliberately refuses to silently widen an already-existing OAuth2 grant's scope. The device's account already had a grant for this app from before TASK-033's scope change, stored under the old read-only-only scope string; the new, differently-scoped login request hits this check every time, which is exactly the "server_error" shown.
• Files changed: tasks/033-write-repository-oauth-scope-for-starring.md (Known limitations section) only — no source changed, since this is Gitea's own intended behavior, not a bug in the app.
• Fix (not yet done): the human product owner needs to revoke UBGitea's existing authorization from the Gitea web UI (Settings → Applications → "Authorized OAuth2 Applications" → revoke), then log in again on the device — this creates a fresh grant under the new scope and should show the consent screen listing write:repository.
• Next recommended task: wait for the human product owner to revoke the old grant and retry login, then confirm starring actually works. Everything else queued from earlier in this session remains pending live confirmation.
• Next owner: Claude, continuing per the standing direction once the human product owner responds.

2026-08-27 (late) — TASK-033 correction: starring needs write:user AND write:repository together

• Agent and role: Claude, direct continuation of the same live session — "그대론데..?" (it's still the same) after the human product owner re-tried with the write:user-only build.
• Diagnosis: added debug-build-only logging of the raw HTTP status + response body on any non-2xx response (HttpTransport.requireSuccess) plus the failure class/message in toggleFavorite's catch block, since source-reading alone had already produced one wrong answer this session. Required adding testOptions { unitTests { isReturnDefaultValues = true } } to app/build.gradle.kts so those android.util.Log calls don't throw inside plain JVM unit tests. Live logcat then showed two direct, unambiguous server responses: requesting write:repository alone got required=[write:user]; requesting write:user alone then got required=[write:repository] right back. Together these confirm /user/starred/{owner}/{repo} requires both scopes at once, not either alone.
• Fix: OAuthClientConfig now requests both write:user and write:repository; the narrowing require() invariant allows exactly those two (confirmed still narrow by a new test using an unrelated write scope, write:organization, added purely for that test).
• Files changed: OAuthClientConfig.kt, OAuthClientConfigTest.kt, HttpTransport.kt, RepositoryListViewModel.kt, app/build.gradle.kts, tasks/033-write-repository-oauth-scope-for-starring.md (corrected throughout, including the earlier incorrect "verified against Gitea's source" claim).
• Checks and results: ./gradlew compileDebugKotlin compileDebugUnitTestKotlin testDebugUnitTest assembleDebug lintDebug BUILD SUCCESSFUL, all unit tests passing, 0 lint errors. Installed on the human product owner's device over wireless adb.
• Known limitations: the device's current session still carries scope from an earlier attempt in this same investigation — needs one more revoke (Gitea Settings → Applications → Authorized OAuth2 Applications) and re-login before starring can be confirmed working. Not yet done — the human product owner was tired and this was left for a later session rather than pushed further tonight.
• Next recommended task: revoke + re-login when convenient, then confirm starring actually works; otherwise continue per the standing direction on everything else still queued from this session (TASK-030/031/032, pinch-zoom/pan, CSV, PDF, Issues/PR pagination).
• Next owner: Claude, continuing per the standing direction.

2026-08-29 — TASK-034: favorite star count doesn't increment after a successful star

• Agent and role: Claude, direct continuation of the same live session — the human product owner confirmed TASK-033's fix worked ("별표 눌러서 즐겨찾기는 되는데") but reported the count itself doesn't update ("카운팅은 안올라가네").
• Commit/diff: on claude/task-015-notifications; feature/repositories/RepositoryListViewModel.kt (+ test additions), tasks/034-favorite-star-count-not-incrementing.md.
• Bug found: toggleFavorite's ALL-list success branch updated only favoriteAction to Starred, never starsCount — the row kept showing whatever count the last full list load had returned, even after a star the server had actually accepted.
• How it was implemented: incremented starsCount by 1 in the same state update that marks the row Starred (optimistic, since Gitea's star endpoint returns 204 with no body — a second network call just to re-fetch one number wasn't worth it). While fixing this, also closed a related gap: since the ALL list can't know a repository's already-starred state on initial load (an existing, accepted limitation from TASK-018/TASK-030), a Starred row's star stayed tappable, and a repeat tap would have re-called star() and double-incremented the displayed count each time — added an early-return guard so a repeat tap on an already-Starred row is now a no-op.
• Files changed: RepositoryListViewModel.kt, RepositoryListViewModelTest.kt, tasks/034-favorite-star-count-not-incrementing.md.
• Checks and results: ./gradlew compileDebugKotlin compileDebugUnitTestKotlin testDebugUnitTest assembleDebug lintDebug BUILD SUCCESSFUL, all unit tests passing (new coverage: starring increments displayed count by 1; a repeat tap after a successful star is a no-op), 0 lint errors. Installed on the human product owner's device over wireless adb.
• Also this turn: the task-015-notifications worktree directory itself had been removed between sessions (its branch and commits were intact); recreated it with git worktree add, plus a fresh local.properties (gitignored, not tracked) pointing at the local Android SDK, before continuing.
• Review findings and resolutions: None from a separate review pass.
• Known limitations: still optimistic, not authoritative — if Gitea's real count ever differs from this app's local +1 (e.g. a concurrent star from another client), the display stays off until the next full list reload. The underlying "can't tell if already starred on load" limitation is unchanged; this only stops it from causing a visible count bug.
• Next recommended task: get live confirmation that the count now increments on tap; otherwise continue per the standing direction on everything else still queued from this session.
• Next owner: Claude, continuing per the standing direction.

2026-08-29 (continued) — TASK-034 follow-up: repeat tap now un-stars instead of doing nothing

• Agent and role: Claude, direct continuation of the same live session — immediately after confirming the count now increments, the human product owner reported "이제 올라가는데 다시 눌렀을때 취소가 안되네" (it goes up now, but tapping again doesn't un-star it).
• Bug found: the first pass's fix for the double-count bug added an early-return guard that made a repeat tap on an already-Starred row a complete no-op — stopped the double-count, but also made the star impossible to undo from the ALL list without switching to the FAVORITES tab, which is not what a filled/tappable star should do.
• How it was implemented: replaced the no-op guard with a real toggle — toggleFavorite now branches on the row's own favoriteAction: not-yet-starred-this-session calls star() (+1, → Starred), already-starred-this-session calls unstar() (-1, coerced at 0, → Idle). Tests updated to match: the old "repeat tap is a no-op" test was replaced with one asserting the repeat tap actually un-stars (both star() and unstar() get called, count and state both revert), plus a new round-trip test (star then unstar lands back at the original count).
• Files changed: RepositoryListViewModel.kt, RepositoryListViewModelTest.kt, tasks/034-favorite-star-count-not-incrementing.md (updated throughout to describe both rounds of this fix).
• Checks and results: ./gradlew compileDebugKotlin compileDebugUnitTestKotlin testDebugUnitTest assembleDebug lintDebug BUILD SUCCESSFUL, all unit tests passing, 0 lint errors. Installed on the human product owner's device over wireless adb.
• Also this turn: the task-015-notifications worktree had been removed from disk between sessions (branch/commits were intact in the main repo); recreated via git worktree add, plus a fresh untracked local.properties pointing at the local Android SDK.
• Review findings and resolutions: None from a separate review pass.
• Known limitations: still optimistic (not re-fetched from the server) in both directions; a failed unstar attempt still collapses to the same flat Failed UI state as a failed star attempt, which can render as not-starred even if the repo is still actually starred server-side — accepted as a minor, harmlessly-retryable gap rather than adding more state to track which action was in flight.
• Next recommended task: get live confirmation that both starring (count up) and un-starring (count back down, tappable again) now work from the ALL list.
• Next owner: Claude, continuing per the standing direction.

2026-08-29 (continued) — TASK-034 third round: make the star/count update optimistic

• Agent and role: Claude, direct continuation of the same live session — with starring and un-starring both working correctly, the human product owner reported it still felt slow: "좋은데 바로바로 반응이 안되네 좀 늦게 카운팅이 변하는 느낌" (good, but doesn't respond immediately — the count feels like it changes a bit late).
• Root cause: every state/count update in toggleFavorite was applied only inside the coroutine, after favoritesApi.star()/unstar() had already returned — meaning the star/count visibly did nothing until the full network round trip to this app's home-NAS-hosted Gitea completed, the same underlying "this host is not a datacenter" latency class as TASK-031's HTTP timeout fix.
• How it was implemented: moved the favoriteAction/starsCount update to run synchronously in toggleFavorite, before viewModelScope.launch { ... } even starts, so the tap feels instant; the coroutine itself now only performs the actual star()/unstar() call. The catch block was extended to roll the optimistic change back (restore the pre-tap count, mark Failed) if the request actually turns out to have failed, so a failure doesn't leave the display stuck showing an action that never really happened. The FAVORITES-list unstar (which removes the whole row) deliberately stays non-optimistic, since reverting a removed row on failure is more jarring than reverting a color/count and wasn't part of what was reported as slow.
• Files changed: RepositoryListViewModel.kt, RepositoryListViewModelTest.kt, tasks/034-favorite-star-count-not-incrementing.md.
• Checks and results: ./gradlew compileDebugKotlin compileDebugUnitTestKotlin testDebugUnitTest assembleDebug lintDebug BUILD SUCCESSFUL, all unit tests passing (new coverage: state/count updates immediately on tap, before the queued coroutine runs on the StandardTestDispatcher; a failed star and a failed unstar each roll the count back to its pre-tap value), 0 lint errors. Installed on the human product owner's device over wireless adb.
• Review findings and resolutions: None from a separate review pass.
• Known limitations: unchanged from earlier in this task — still optimistic rather than server-authoritative in both directions (accepted tradeoff), and the underlying "can't tell if already starred on load" limitation from TASK-018/TASK-030 is untouched.
• Next recommended task: get live confirmation that starring/un-starring now feels instant.
• Next owner: Claude, continuing per the standing direction.

2026-08-29 (continued) — TASK-035: remove the redundant per-file "커밋" button in the code browser

• Agent and role: Claude, direct continuation of the same live session — "현재 보고있는 페이지 우상단에 커밋 버튼은 이제 필요 없지 않나" (the Commit button in the top-right of the current page isn't needed anymore, is it).
• Commit/diff: on claude/task-015-notifications; feature/codebrowser/CodeBrowserScreen.kt, feature/branchdetail/BranchDetailScreen.kt, strings_codebrowser.xml, tasks/035-remove-redundant-code-browser-commit-button.md.
• Confirmed the observation was correct before acting on it: traced the header's "커밋" button (onViewHistory) all the way to its single call site in BranchDetailScreen.kt and found it just switched the pager to page 1 — the exact same action the top-level "커밋" tab's own onClick already performs a few lines above it. TASK-031's rename (both controls used to be independently labeled "히스토리"/differently-purposed before that) is what made the duplication visually obvious.
• How it was implemented: removed the button and the onViewHistory parameter threaded through CodeBrowserScreen/BrowserHeader, the call site in BranchDetailScreen.kt, and the now-unused codebrowser_history string resource (confirmed unused via a repo-wide search first). BrowserHeader's title/ref layout simplified from a Row-wrapped Column to a plain Column now that there's no trailing button to share the row with. Also fixed a stale "History" word in a doc comment one line above (predating TASK-031's rename).
• Files changed: CodeBrowserScreen.kt, BranchDetailScreen.kt, strings_codebrowser.xml, tasks/035-remove-redundant-code-browser-commit-button.md.
• Checks and results: ./gradlew compileDebugKotlin compileDebugUnitTestKotlin testDebugUnitTest assembleDebug lintDebug BUILD SUCCESSFUL, all unit tests passing, 0 lint errors. Installed on the human product owner's device over wireless adb.
• Review findings and resolutions: None from a separate review pass.
• Known limitations: None identified.
• Next recommended task: get live confirmation the header looks right without the button; otherwise continue per the standing direction on the rest of this session's queued items.
• Next owner: Claude, continuing per the standing direction.

2026-08-29 (continued) — TASK-036: push notification when a favorited repository gets a new push

• Agent and role: Claude, direct continuation of the same live session — building the last remaining big feature from earlier this session's queue, confirmed with the human product owner before starting given it needed a new permission and dependency.
• Commit/diff: on claude/task-015-notifications; new core/notifications/ package (FavoritePushDetector, LastSeenPushStore + SharedPreferencesLastSeenPushStore, FavoritePushNotifier, FavoritePushCheckWorker, FavoritePushScheduler), two new use cases in RepositoryBrowseUseCases.kt (GetLatestPushEpochMillisUseCase, ListFavoritedRepositoryCoordinatesUseCase), MainActivity.kt (scheduling + runtime permission request), AndroidManifest.xml (POST_NOTIFICATIONS), a new notification icon and string resources, gradle/libs.versions.toml/app/build.gradle.kts (androidx.work:work-runtime-ktx 2.11.2), matching tests, tasks/036-favorite-repo-push-notifications.md.
• Feature implemented: a 15-minute WorkManager periodic job (network-constrained) checks every favorited repository's most recent push time — reusing the exact same "newest branch commit time" heuristic RepositoryListViewModel already uses for the repository list's own "마지막 push" row, now extracted as a shared, reusable GetLatestPushEpochMillisUseCase — and posts a local notification when it advances past what was last recorded.
• How it was implemented: FavoritePushDetector is pure comparison logic (no Android/network dependency), deliberately never reporting a repository as "newly pushed" on its first sighting (only a real advance past a previously-recorded timestamp counts), which prevents the very first background check this feature ever runs from firing one notification per already-favorited repository regardless of actual recent activity. Storage is SharedPreferences (one long per favorited repository), not Room, since docs/architecture.md reserves Room specifically for offline caching. The worker is scheduled unconditionally on every app launch (ExistingPeriodicWorkPolicy.KEEP makes repeat calls a no-op) and instead gates internally — it just returns success immediately when there's no stored session or no favorited repositories, so the scheduler itself doesn't need to track login state. POST_NOTIFICATIONS is requested at runtime on API 33+ from MainActivity; a denial degrades safely (the worker still runs and updates its baseline, NotificationManagerCompat.notify() is explicitly permission-checked before being called at all, matching its @RequiresPermission lint contract as a deliberate no-op rather than a caught exception).
• Files changed: see tasks/036-favorite-repo-push-notifications.md's Scope/Writable paths sections for the full list.
• Checks and results: ./gradlew compileDebugKotlin compileDebugUnitTestKotlin testDebugUnitTest assembleDebug lintDebug BUILD SUCCESSFUL, all unit tests passing (new coverage: FavoritePushDetectorTest — first-sight never notifies, an actual advance does, unchanged/older doesn't, multiple repositories evaluated independently; new RepositoryBrowseUseCasesTest coverage for both new use cases, including multi-page pagination and a repository with no branches/no commit time), 0 lint errors. Installed on the human product owner's device over wireless adb; live-confirmed the POST_NOTIFICATIONS runtime prompt actually appeared and was granted (verified via dumpsys package), and app launch/scheduling produced no crash in logcat.
• Review findings and resolutions: None from a separate review pass.
• Known limitations: no deep link from the notification to the specific repository (opens the app at its normal entry point instead — a genuine follow-up-sized piece of work, not attempted here); no in-app way to disable this per-repository or change the interval; un-favoriting a repository drops its stored baseline on the next worker run, so re-favoriting it later starts fresh rather than retroactively notifying for what happened while un-favorited (a deliberate, simpler default). Actual end-to-end notification delivery (a real push landing, 15 minutes elapsing, a notification appearing) hasn't been observed yet in this session — that specifically doesn't fit inside one live-testing session's timeframe.
• Next recommended task: wait for a real push to a favorited repository and confirm the notification actually appears; otherwise this closes out the last big item from this session's queue — remaining work is live-confirmation of everything already built (TASK-030 through TASK-035, plus pinch-zoom/CSV/PDF/Issues-PR pagination from earlier).
• Next owner: Claude, continuing per the standing direction.

2026-08-29 (continued) — TASK-036 follow-up: deep-link the favorite-push notification

• Agent and role: Claude, direct continuation of the same live session — "계속 이어서 개발해줘 멈추지말고" (keep developing, don't stop) after TASK-036's initial commit. Picked up the deep-link follow-up TASK-036 itself had explicitly flagged as scoped out ("no deep link yet... noted as a natural follow-up").
• Commit/diff: on claude/task-015-notifications; RepositoryBrowseUseCases.kt (ListFavoritedRepositoryCoordinatesUseCase → ListFavoritedRepositoriesUseCase, now returns full RepositorySummary), FavoritePushNotifier.kt (notifyNewPush takes an optional defaultBranch, attaches owner/name/ref string extras to the tap PendingIntent), FavoritePushCheckWorker.kt (looks up each repository's defaultBranch before notifying), MainActivity.kt (new pendingFavoritePushRoute Activity-property bridge + consumeFavoritePushTarget, wired into onCreate/onNewIntent), matching test updates, tasks/036-favorite-repo-push-notifications.md (updated throughout).
• Feature implemented: tapping the favorite-push 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.
• How it was implemented: since the underlying push-detection only tracks one scalar "latest push time" per repository (not which branch produced it), the deep link targets the repository's default branch rather than the specific pushed branch — a correct, useful "take me to this repository" action even though it isn't always literally the branch that changed. MainActivity already had a consumeCallback pattern (read-and-clear one-shot intent data, originally for the OAuth redirect) that a new consumeFavoritePushTarget mirrors exactly. Since routeStack is Compose state scoped inside setContent, not a plain Activity field, the bridge from plain Activity code (onCreate/onNewIntent) into composition is a mutableStateOf<Route.BranchDetail?> held as a regular Activity property, read by a LaunchedEffect inside setContent that pushes it onto routeStack once set.
• Files changed: see tasks/036-favorite-repo-push-notifications.md's Scope/Writable paths sections.
• Checks and results: ./gradlew compileDebugKotlin compileDebugUnitTestKotlin testDebugUnitTest assembleDebug lintDebug BUILD SUCCESSFUL, all unit tests passing (new coverage: GetLatestPushEpochMillisUseCase's max-across-pages/no-commit-time/no-branches cases; ListFavoritedRepositoriesUseCase's pagination and defaultBranch preservation), 0 lint errors. Installed on the human product owner's device over wireless adb.
• Live verification: simulated a notification tap directly via adb shell am start with the exact three extras FavoritePushNotifier would set — the app opened directly at RobotAutomationDevelopment-Dept/LGES-OC5-PtoP-Welder's file browser on branch main, screenshot-confirmed, no crash. This proves the deep-link navigation half works correctly; the actual trigger half (a real push firing the notification organically) still isn't observed within this session's timeframe.
• Review findings and resolutions: None from a separate review pass.
• Known limitations: deep link targets the default branch, not necessarily the specifically-pushed branch (by design, see above); a repository with no default branch still notifies, just without deep-link extras.
• Next recommended task: this closes out the last explicitly-scoped item from this session's feature queue. Remaining work is live-confirmation of everything already built across this whole session (TASK-027 through TASK-036) — pinch-zoom/CSV/PDF viewers, Issues/PR pagination, the green theme, and this notification feature's actual end-to-end firing.
• Next owner: Claude, continuing per the standing direction.

2026-08-29 (continued) — TASK-037: already-starred repositories show filled on the ALL list's first load

• Agent and role: Claude, direct continuation of the same live session — "계속 이어서 개발해줘 멈추지말고" (keep developing, don't stop) after TASK-036's deep-link follow-up. Picked up a real, previously-accepted-not-fixed known limitation from TASK-018/TASK-030 rather than waiting on further live confirmation.
• Commit/diff: on claude/task-015-notifications; feature/repositories/RepositoryListViewModel.kt (+ test additions), tasks/037-already-starred-repos-show-filled-on-load.md.
• Feature implemented: the ALL repository list now shows a filled star from its very first load for any repository the account has already starred — not just after this session's own toggle interaction.
• How it was implemented: loadStarredCoordinatesOnce() fetches the account's full starred-repository set once per session via the same /user/starred endpoint already used for the FAVORITES tab (Gitea's plain repository-list response has no "is this starred by me" field, and calling a per-repository IsStarring endpoint once per row would have turned one list load into N+1 requests) — mirrors loadOrganizationsOnce's exact shape (cache-check, non-fatal try/catch fallback). toggleFavorite's success paths now also keep this cache directly in sync (+/- the toggled repository) so later reloads within the same session stay consistent without a re-fetch; refreshRepositories()/logout() invalidate/clear it the same way the equivalent repositorySnapshots/cachedOrganizations caches already are.
• Files changed: RepositoryListViewModel.kt, RepositoryListViewModelTest.kt, tasks/037-already-starred-repos-show-filled-on-load.md.
• Checks and results: ./gradlew compileDebugKotlin compileDebugUnitTestKotlin testDebugUnitTest assembleDebug lintDebug BUILD SUCCESSFUL, all 28 tests in RepositoryListViewModelTest passing including every pre-existing one unmodified (new coverage: an already-starred repository shows filled on first load while a sibling shows outlined; un-starring then reloading the ALL list confirms the cache itself, not just the visible row, updated), 0 lint errors. Installed on the human product owner's device.
• Live verification: confirmed RobotAutomationDevelopment-Dept/LGE-OC6-Inline-CylinderTypeWelder was genuinely starred server-side via the FAVORITES tab (★ 1 shown there), then located it on the ALL list (page 2) after a fresh app launch — showed filled green ★ 1 immediately with no tap needed, screenshot-verified, no crash.
• Review findings and resolutions: None from a separate review pass.
• Known limitations: still session-scoped (re-fetches on a fresh session, same as every other cached list in this app); doesn't reflect a starred-set change made elsewhere (Gitea web, another device) until the next pull-to-refresh or re-login.
• Next recommended task: this closes a real, previously-documented gap rather than adding new surface area. Remaining work across this whole session is now mostly live-confirmation of already-built features (TASK-027 through TASK-036) that haven't been directly exercised by the human product owner yet.
• Next owner: Claude, continuing per the standing direction.

2026-08-29 (continued) — TASK-028 follow-up: visible feedback for an out-of-range page-jump

• Agent and role: Claude, direct continuation of the same live session — "계속 이어서 개발해줘 멈추지말고" (keep developing, don't stop). Picked up a small, contained item TASK-028 itself had documented as a known limitation.
• Commit/diff: on claude/task-015-notifications; feature/workitems/WorkItemsScreen.kt, strings_workitems.xml, tasks/028-issues-prs-numbered-pagination.md.
• Fix implemented: the Issues/PR numbered-pagination page-jump field previously accepted any typed number and silently clamped it to [1, totalPages] only on submit (typing "999" would quietly land on the last page with no explanation). It now sets isError/supportingText on the field whenever the currently-typed value falls outside that range, making the clamp visible before the tap instead of after.
• How it was implemented: pure Compose-only change (isOutOfRange derived from the field's own current text, compared against totalPages) — submitting still clamps exactly as before, this only adds visible feedback. No test coverage added since this file's pagination UI has never had dedicated tests (matches this codebase's established pattern of not unit-testing pure Compose screens).
• Files changed: WorkItemsScreen.kt, strings_workitems.xml, tasks/028-issues-prs-numbered-pagination.md.
• Checks and results: ./gradlew compileDebugKotlin compileDebugUnitTestKotlin testDebugUnitTest assembleDebug lintDebug BUILD SUCCESSFUL, all unit tests passing, 0 lint errors. Installed on the human product owner's device over wireless adb.
• Review findings and resolutions: None from a separate review pass.
• Known limitations: same as the rest of TASK-028 — not yet seen live against a repository with enough real issues/PRs to populate the numbered UI, since no such repository was found this session.
• Next recommended task: this was a small, contained polish item. Larger remaining candidates (e.g. a reactive 401-retry fallback at the network layer, per-repository notification settings) were considered but judged too large/risky for unrequested autonomous continuation without a dedicated task scoping pass — flagging them for the human product owner's direction rather than proceeding further unrequested into security-adjacent or larger-surface-area territory.
• Next owner: Claude, continuing per the standing direction once the human product owner responds, or awaiting live confirmation of everything already built this session.

2026-08-29 (continued) — TASK-038: Settings screen with opt-in auth-retry and a favorite-push toggle

• Agent and role: Claude, direct continuation of the same live session. Presented two candidate next-steps (reactive 401 retry / per-toggle push notification settings) and their tradeoffs; the human product owner asked for both, with the reactive retry explicitly framed as something the Settings screen should gate ("설정화면에서 설정 해두면 동작하고 안해두면 동작 안하게").
• Commit/diff: on claude/task-015-notifications; new core/settings/ (AppSettingsStore, SharedPreferencesAppSettingsStore, AppSettingsSession), new feature/settings/ (SettingsViewModel, SettingsScreen), Route.Settings + RouteStackSaver, a "설정" button on RepositoryListScreen's top bar, new ReactiveTokenProvider interface + shared callAuthenticated helper in GiteaRepositoryBrowserApi.kt, RefreshingTokenProvider.forceRefresh(), all four Gitea API classes (GiteaRepositoryBrowserApi/GiteaHistoryApi/GiteaWorkItemsApi/GiteaNotificationsApi) gained a defaulted reactiveAuthRetryEnabled parameter, all five ViewModel.Factorys that construct one of them wired to the new setting, FavoritePushCheckWorker gated on the push-notification toggle, matching tests, tasks/038-settings-screen-reactive-auth-retry-push-toggle.md.
• Feature implemented: (A) an opt-in (default off) reactive fallback — a live 401 despite proactive refresh having judged the token fine now optionally retries once with a forcibly-refreshed token before falling back to the existing re-login flow; (B) TASK-036's background push checker can now be turned off entirely from a new Settings screen, closing that task's own documented limitation.
• How it was implemented: ReactiveTokenProvider is a separate interface from the existing fun interface BearerTokenProvider (not an addition to it), specifically so every existing test fake written as a plain BearerTokenProvider { "token" } lambda keeps compiling — only RefreshingTokenProvider also implements it, and a new shared callAuthenticated helper checks tokenProvider as? ReactiveTokenProvider before relying on it, falling back to the old single-attempt behavior otherwise. All four API classes' near-identical authenticated/get wrappers now delegate to this one shared helper instead of duplicating the retry orchestration four times. forceRefresh() always attempts a refresh regardless of stated expiry (unlike the existing proactive accessToken(), which would just hand back the same still-time-valid-looking token again), reusing the exact same mutex and refresh-or-fall-back logic (factored into a shared private refreshOrFallBack) so a reactive retry racing an in-flight proactive refresh still shares one attempt at the single-use rotating refresh token. Every new constructor parameter defaults to preserving old behavior exactly, so no existing call site or test needed to change.
• Files changed: see tasks/038-settings-screen-reactive-auth-retry-push-toggle.md's Scope/Evidence sections for the full list.
• Checks and results: ./gradlew compileDebugKotlin compileDebugUnitTestKotlin testDebugUnitTest assembleDebug lintDebug BUILD SUCCESSFUL, every pre-existing test across all four API classes and RefreshingTokenProvider passing unmodified, plus new coverage (forceRefresh()'s behavior, callAuthenticated's retry decision matrix, a Route.Settings round-trip), 0 lint errors. Installed on the human product owner's device over wireless adb.
• Live verification: opened Settings from the new button; both switches visibly toggled (screenshot-confirmed each state change, including exact tap-coordinate discovery via uiautomator dump after an initial miss); backed out and re-entered Settings, confirming both toggles persisted via SharedPreferences; restored both to their defaults afterward; logcat clean of any crash throughout.
• Review findings and resolutions: None from a separate review pass.
• Known limitations: reactive auth retry's actual live effect (recovering from a genuine 401 without forcing re-login) hasn't been observed end-to-end, since that requires a rare, hard-to-trigger real revocation event — covered instead by direct unit tests of the retry orchestration. Favorite push notifications remain one app-wide toggle, not per-repository (deliberate scope decision, not an oversight).
• Next recommended task: this closes the two explicitly-requested items from this "continue developing" stretch. Remaining work across the whole session is largely live-confirmation of already-built features that haven't been directly exercised yet (pinch-zoom/CSV/PDF viewers, Issues/PR numbered pagination with real data, the actual favorite-push notification firing end-to-end).
• Next owner: Claude, continuing per the standing direction.

2026-08-29 (continued) — TASK-039: Design pass — app icon, visibility badge, header truncation, PR-label Korean-ization

• Agent and role: Claude, direct continuation of the same live session. The human product owner asked for an open-ended design review ("디자인 수정해줄래? 앱의 아이콘부터 해서 전체적으로 확인해보고 부족한 부분 고쳐줘") after all previously-requested features were built. Proceeded autonomously, screen by screen, per the standing direction.
• Commit/diff: on claude/task-015-notifications; new launcher-icon drawables and mipmap-anydpi-v26 wrappers, AndroidManifest.xml's android:icon/android:roundIcon, RepositoryListScreen.kt's new VisibilityBadge composable and references-header title truncation, strings_workitems.xml/ strings_notifications.xml's Pull Request → PR, tasks/039-design-pass-app-icon-and-visual-polish.md.
• Feature implemented: (1) a custom adaptive app icon replacing Android's bare default (an original green git-branch glyph matching the app's own primary color, not a reproduction of Gitea's logo); (2) a compact styled badge for the repository-list visibility label, replacing an unstyled full-width text line; (3) 2-line ellipsis truncation on the references screen's repository-name header, which a real long-named repository was wrapping to 3 lines; (4) "Pull Request" → "PR" in the two string resources that were the only English text left in an otherwise fully-Korean UI — also the cause of a visible line-wrap on the live notifications list, since it was the widest word in a Row with no wrap handling.
• How it was implemented: the icon uses only vector primitives (arc-path circles, stroked lines), no icon library, matching this app's established convention. VisibilityBadge reuses the same Surface + RoundedCornerShape + labelSmall construction already used for FilterChip elsewhere on the same screen. "PR" was already this app's own convention in five other strings (workitems_pr_refs, workitems_permission_denied, the "PR/이슈" button label, etc.) — only the tab label and the notifications subject label had been left as the English full phrase.
• Files changed: see tasks/039-design-pass-app-icon-and-visual-polish.md's Scope/Evidence sections.
• Checks and results: ./gradlew compileDebugKotlin testDebugUnitTest assembleDebug lintDebug BUILD SUCCESSFUL (run twice, once per round of changes), all unit tests passing, 0 lint errors.
• Live verification: installed on the human product owner's device over wireless adb after each round. Icon confirmed via the Recents/task-switcher view. Badge and header truncation confirmed via screenshot on a real long-named repository. PR-label fix confirmed via screenshot against the notifications "전체" tab with real PR/issue data — every row now fits "PR" on one line alongside its state label instead of wrapping. Dark mode forced via adb shell cmd uimode night yes and reviewed for the repository list and references screens (no contrast issues found), then restored.
• Review findings and resolutions: None from a separate review pass.
• Known limitations: work-items/code-browser screens still don't show their own repository/branch context in a header (needs ViewModel-layer changes, scoped out of this visual-polish batch); dark-mode review only covered two of the app's screens so far; the code browser, commit history/diff, and work-item/PR detail views with real content haven't been reviewed yet — this is the first batch from an ongoing design-review pass, not a complete one.
• Next recommended task: continue the design review into the code browser (file tree, text/image/CSV/PDF viewers), commit history/diff view, work-item/PR detail screens with real content, and extend the dark-mode check to the remaining screens; separately, consider a small follow-up task to surface repository/branch context in the work-items and code-browser headers.
• Next owner: Claude, continuing per the standing direction.

2026-08-29 (continued) — TASK-039 follow-up: extended design review, no further changes needed

• Agent and role: Claude, direct continuation of the same live session, continuing the design-review pass per the standing direction after committing TASK-039's first batch of fixes.
• What was reviewed: the code browser's file tree (폴더/파일 rows, breadcrumb), the commit history list, and the per-file diff view (tapping into an individual file's change from a commit) — both in light and dark mode (adb shell cmd uimode night yes/no).
• Outcome: no code changes needed. The per-file diff view already does proper git-style red/green color-coding (DiffAddedColor for additions, MaterialTheme.colorScheme.error for removals) in a side-by-side 기존(before)/변경(after) layout with a monospace font, and it holds up cleanly in dark mode too. The file tree and commit list are visually consistent with the rest of the app's list-row pattern (title + metadata, no icon library, matching the app-wide convention).
• Files changed: tasks/039-design-pass-app-icon-and-visual-polish.md's Evidence/Known limitations sections updated to record this review pass; no source changes.
• Next recommended task: continue into work-item/PR detail views with real content and the text/image/CSV/PDF file viewers, and extend the dark-mode pass to notifications/settings/work-items.
• Next owner: Claude, continuing per the standing direction.

2026-08-29 (continued) — TASK-040: repository-list header overflow menu (code-only, no device install)

• Agent and role: Claude, direct continuation of the same live session. The human product owner asked to stop growing the repository list's top bar with more always-visible buttons and instead collapse 설정/알림/로그아웃 behind a hamburger-style overflow menu, and explicitly asked for code only this round with wireless debugging paused ("잠시 무선 디버깅 하지말고 코드만 수정해줘").
• Commit/diff: on claude/task-015-notifications; RepositoryListScreen.kt's header now shows one "☰" IconButton opening a DropdownMenu (설정/알림/로그아웃) instead of three separate OutlinedButtons; tasks/040-repository-list-header-overflow-menu.md.
• How it was implemented: new private OverflowMenuButton composable takes the exact same three callbacks (onViewSettings/onViewNotifications/onLogout) the header already received — presentation-only change, no navigation/ViewModel/use-case code touched. Uses the plain "☰" Unicode glyph rather than a drawable icon, consistent with this app's established no-icon-library convention (the same convention already used for ★/☆ elsewhere).
• Files changed: feature/repositories/RepositoryListScreen.kt, tasks/040-repository-list-header-overflow-menu.md.
• Checks and results: ./gradlew compileDebugKotlin testDebugUnitTest assembleDebug lintDebug BUILD SUCCESSFUL, all unit tests passing unmodified, 0 lint errors.
• Live verification: intentionally not done this round — wireless debugging was paused at the human product owner's request. Code is ready to install and screenshot-verify (light and dark mode) next session.
• Review findings and resolutions: None from a separate review pass.
• Known limitations: not yet live-confirmed on-device (see task file).
• Next recommended task: once wireless debugging resumes, install and screenshot-verify the new overflow menu (button sizing/position, dropdown legibility, correct navigation for each item, both light and dark mode), then continue the broader design-review pass (work-item/PR detail views, file viewers) from where TASK-039 left off.
• Next owner: Claude, continuing per the standing direction once wireless debugging resumes or further code-only work is requested.

2026-08-29 (continued) — TASK-040 follow-up: live-verified once wireless debugging resumed

• Agent and role: Claude, direct continuation of the same live session. The human product owner said "다시 해줘" once wireless debugging was back on, picking up exactly where TASK-040 left off (install and live-verify the code-only overflow-menu change).
• Commit/diff: on claude/task-015-notifications; tasks/040-repository-list-header-overflow-menu.md updated from "not yet live-verified" to confirmed, with the live-verification evidence recorded.
• Live verification: installed the already-built APK over wireless adb. Screenshot-confirmed the "☰" button renders correctly next to the title in both portrait and the foldable's unfolded landscape layout; opened the dropdown and confirmed all three items (설정/알림/로그아웃) render and are positioned correctly; tapped 설정 and confirmed it navigates to the Settings screen exactly like the old button did. Repeated the same check with adb shell cmd uimode night yes — both the button and dropdown hold good contrast in dark mode — then restored night no.
• Files changed: tasks/040-repository-list-header-overflow-menu.md only; no source changes (the code from the previous entry was already correct).
• Next recommended task: continue the broader design-review pass (work-item/PR detail views with real content, file viewers) from where TASK-039 left off.
• Next owner: Claude, continuing per the standing direction.

2026-08-29 (continued) — TASK-041: favorite star reverted / missing from favorites after tab switch

• Agent and role: Claude, direct continuation of the same live session. Live bug report mid-turn while reviewing another screen: "즐겨찾기 누르고나면 카운팅은 되는데 즐겨찾기 탭에 가면 방금 누른 항목이 안떠있다. 그리고 다시 원래 탭인 레포지토리로 가보면 다시 즐겨찾기가 풀려있어." Paused the in-progress work and switched to reproducing and fixing this immediately, per the standing priority of live bug reports over open-ended review work.
• Commit/diff: on claude/task-015-notifications; RepositoryListViewModel.kt's toggleFavorite reworked to patch repositorySnapshots (not just starredCoordinatesCache) on every successful star/unstar; two new tests in RepositoryListViewModelTest.kt; tasks/041-favorite-star-reverts-after-tab-switch.md.
• Root cause: repositorySnapshots (the per-mode full-repository-list cache, fetched once per session and reused on every later visit to that mode) was never patched by toggleFavorite — only the separate starredCoordinatesCache was. So the star icon correctly showed filled (from the patched cache), but the displayed starsCount reverted to whatever was cached from the very first load of that mode, and a favorites tab already cached from an earlier visit kept silently missing a newly-starred repository.
• How it was diagnosed: reproduced live on-device (star a repository, switch to 즐겨찾기, switch back — watched the star/count go wrong exactly as reported). Added temporary debug-only Log.w logging of the star/unstar HTTP response directly in GiteaRepositoryBrowserApi to rule out a failed request — confirmed HTTP 204 (success) every time, isolating the bug to client-side caching, not the network call. Removed the temporary logging once the root cause was confirmed.
• How it was fixed: tried a "clear the whole cache on every toggle, force a refetch" approach first; reverted after live testing showed Gitea's own starsCount on the plain repository-listing endpoint lags slightly behind a star/unstar (the /user/starred listing reflected a toggle sooner) — forcing a refetch would trade one race condition for another. Switched to a local patch instead: two new private helpers (adjustCachedStarCounts, removeFromCachedSnapshot) keep every cached snapshot that includes the toggled repository consistent with what the app already knows happened, without a network round trip. A star also invalidates just the FAVORITES snapshot key if it was already cached (can't surgically insert a row without a full domain object at that call site) so the next visit fetches it fresh instead of silently missing the new star.
• Files changed: feature/repositories/RepositoryListViewModel.kt, feature/repositories/RepositoryListViewModelTest.kt (test file, actually under app/src/test/java/...), tasks/041-favorite-star-reverts-after-tab-switch.md.
• Checks and results: ./gradlew compileDebugKotlin compileDebugUnitTestKotlin testDebugUnitTest assembleDebug lintDebug BUILD SUCCESSFUL, every pre-existing favorite-toggle test passing unmodified plus two new regression tests, 0 lint errors.
• Live verification: installed over wireless adb. Starred a never-before-touched repository (LGD-AP4-RPR) from the ALL tab, confirmed it appeared in 즐겨찾기 (★1), switched back to 전체 저장소 and confirmed the star/count stayed correct (★1) instead of reverting — screenshots at each step.
• Review findings and resolutions: None from a separate review pass.
• Known limitations: None outstanding for this task.
• Next recommended task: resume the design-review pass (TASK-039's known limitations: work-item/PR detail views with real content, file viewers, extended dark-mode coverage) from where it was paused for this bug fix.
• Next owner: Claude, continuing per the standing direction.

2026-08-29 (continued) — TASK-042: colored status badges for issue/PR state

• Agent and role: Claude, direct continuation of the same live session, per "쭉 이어서 개발이랑 디자인 진행해줄래?" — resuming the paused design-review pass named as next work in TASK-041's log entry.
• Investigation: first re-verified the review item flagged as unresolved at the pause point — whether issue/PR body text renders correctly for real content (the one PR viewed earlier happened to have no body). Opened the real "PostActivated 관련 추가 필요" issue (multi-paragraph Korean body plus an embedded C# code block) and confirmed it renders correctly end to end — no bug found there. While doing that, noticed the 열림/닫힘/병합됨 state label next to it (and next to every issue/PR, in both list rows and detail headers) was a plain, uncolored bodySmall line, no more visually prominent than the #8 issue number beside it — inconsistent with the colored VisibilityBadge treatment TASK-039 already gave 공개/비공개 on the repository list.
• Commit/diff: on claude/task-015-notifications; feature/workitems/WorkItemsScreen.kt gained a StatusBadge composable (two thin state-typed overloads sharing one rendering implementation) replacing the four plain-text state-label call sites (IssueRow, PullRequestRow, IssueDetailView, PullRequestDetailView); tasks/042-workitem-status-badges.md.
• How it was implemented: reused existing Material3 theme roles rather than inventing new colors — OPEN gets primaryContainer (the same green VisibilityBadge uses for a public repository), CLOSED gets the baseline errorContainer Theme.kt already reserves for closed/removed states, and MERGED (a third state GitHub/Gitea conventionally color purple, which this theme has no role for) gets the teal tertiaryContainer instead. Both light and dark mode are handled automatically since no new hardcoded color was introduced.
• Files changed: feature/workitems/WorkItemsScreen.kt, tasks/042-workitem-status-badges.md.
• Checks and results: ./gradlew compileDebugKotlin compileDebugUnitTestKotlin testDebugUnitTest assembleDebug lintDebug BUILD SUCCESSFUL, all existing unit tests passing unmodified (a pure presentation change with no new branching logic beyond the enums' own exhaustive whens), 0 lint errors.
• Live verification: installed over wireless adb. RobotAutomationDevelopment-Dept/OC5-PilotLine- RectangleTypeWelder PR tab: confirmed a teal "병합됨" badge on two merged PRs and a green "열림" badge on the third, side by side (screenshot); opened the merged PR's detail view and confirmed the same teal badge in the header (screenshot). Repeated with adb shell cmd uimode night yes — both badge colors keep good contrast against the dark surface (screenshot) — then restored night no.
• Review findings and resolutions: None from a separate review pass.
• Known limitations: NotificationsScreen.kt renders its own separate PR/이슈 상태 column as plain text — the same visual gap, in a different screen, not touched in this pass to keep it scoped to what was actually being reviewed. Did not visually confirm the red CLOSED badge with this fix installed (no real closed issue/PR was opened live this session) — low risk, since the color mapping reuses the same errorContainer role already used unconditionally elsewhere in the app.
• Next recommended task: continue the design-review pass — the text/image/CSV/PDF file viewers (not yet reviewed this session), and consider extending today's status-badge fix to NotificationsScreen.kt for consistency.
• Next owner: Claude, continuing per the standing direction.