docs: switch the engineering contract to Claude-only development

Claude becomes implementer; review moves to a separate Claude session or the product owner. README and product brief now describe the application as it is: the starring write scope, the removed compare view, and the C#/C++ focus.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

AGENTS.md

@@ -27,21 +27,22 @@ Do not implement a feature without an acceptance-criteria task file. If requirem
 
 ## Agent roles
 
-### Codex — implementer and integrator
+Since 2026-09-28 the project is developed by Claude alone, directed by the human product owner. Earlier tasks and log entries that name Codex as owner or reviewer are historical; a status of "pending Codex review" now means "pending review" by the roles below.
 
-- Owns repository edits unless the task explicitly transfers ownership.
+### Claude — implementer and integrator
+
+- Owns repository edits within the task's writable paths.
 - Inspects existing code before changing it.
 - Implements the smallest coherent change satisfying the task.
 - Runs required checks and records evidence.
 - Resolves review findings and keeps documentation synchronized.
 
-### Claude — independent reviewer and design critic
+### Reviewer — a separate Claude review session or the human product owner
 
-- Starts read-only unless explicitly assigned implementation ownership.
+- Reviews in a session that did not write the change, and stays read-only while reviewing.
 - Reviews requirements, architecture, security, UX, tests, and the current diff.
-- Does not rewrite code while reviewing.
 - Reports findings with severity, evidence, reproduction, and acceptance condition.
-- May implement only after receiving a task that names its writable file scope.
+- Uses `prompts/claude-review.md`.
 
 ### Human product owner
 
@@ -50,10 +51,11 @@ Do not implement a feature without an acceptance-criteria task file. If requirem
 
 ## Single-writer protocol
 
-- Only one agent may write a file during a task.
+- Only one session may write a file during a task.
-- Codex and Claude must not edit the same working tree concurrently.
+- Two sessions must not edit the same working tree concurrently. A session running in a worktree writes only inside that worktree.
 - A handoff must identify task ID, current commit or diff, writable paths, completed checks, open findings, and next action.
 - Never accept a review based only on “looks good.” Use acceptance criteria and test evidence.
+- Finished work is merged into `master`, so that a new worktree starts from the current application rather than an old snapshot.
 
 ## Required work cycle
 
@@ -63,7 +65,7 @@ Do not implement a feature without an acceptance-criteria task file. If requirem
 4. Implement.
 5. Run the checks listed in the task.
 6. Review the diff against acceptance criteria.
-7. Ask the independent reviewer to inspect it.
+7. Ask the reviewer to inspect it.
 8. Resolve findings and rerun checks.
 9. Update task evidence and hand off.
 
@@ -119,7 +121,7 @@ Each finding must include file and line, concrete impact, evidence, and the cond
 - Keep commits focused on one task.
 - Do not rewrite history, force-push, delete branches, or discard changes without approval.
 - Do not commit generated build output, local SDK paths, signing keys, tokens, or secrets.
-- Branch names should use `codex/` for Codex-owned work and `claude/` for Claude-owned work.
+- Branch names use the `claude/` prefix. Existing `codex/` branches are historical.
 
 ## Definition of done
 

CLAUDE.md

@@ -2,6 +2,8 @@
 
 Read `AGENTS.md` first. It is the canonical instruction source.
 
-Your default role in this repository is independent reviewer and design critic. Stay read-only unless the human product owner or an assigned task explicitly grants you implementation ownership and lists writable paths.
+Your default role in this repository is implementer and integrator: you own repository edits within the writable paths of an acceptance-criteria task file. When asked for a review, review in a session that did not write the change, stay read-only, use `prompts/claude-review.md`, and report findings before summaries.
 
-For a review, use `prompts/claude-review.md` and report findings before summaries. Never request or expose the OAuth client secret.
+The application's current state is on the development branch and in `docs/development-log.md`. If the checkout you are in shows only a placeholder home screen, it is an old snapshot: check `git log --all` before describing what the application does.
+
+Never request or expose the OAuth client secret.

README.md

@@ -2,21 +2,20 @@
 
 Android client for the Ubisam Paju Gitea instance.
 
-The repository currently contains the engineering harness that governs collaborative development by Codex and Claude. Product code will be bootstrapped through the tasks under `tasks/`.
+The application signs in with Gitea OAuth and lets employees browse repositories, branches, files, commit history and diffs, issues, pull requests and notifications. It is developed by Claude under the rules in `AGENTS.md`; every change goes through a task file under `tasks/` and is recorded in `docs/development-log.md`.
 
 ## Start here
 
 1. Read `AGENTS.md`.
 2. Read `docs/product.md` and `docs/architecture.md`.
-3. Select one task from `tasks/`.
+3. Select or write one task under `tasks/`.
-4. Assign one writer and one independent reviewer.
+4. Record build and test evidence before marking the task complete.
-5. Record build and test evidence before marking the task complete.
 
 OAuth uses Authorization Code with PKCE and does not use a client secret.
 
 ## Local checks
 
-Open the repository root in Android Studio, or use JDK 17 with Android SDK 36 installed and run:
+Open the repository root in Android Studio, or use JDK 17 or later with Android SDK 36 installed (Android Studio's bundled `jbr` works as `JAVA_HOME`) and run:
 
 ```text
 ./gradlew assembleDebug

docs/collaboration.md

@@ -1,8 +1,8 @@
-# Codex and Claude collaboration
+# Collaboration
 
 ## Operating model
 
-One agent writes; the other reviews. Roles can rotate between tasks, but ownership cannot be ambiguous within a task.
+Claude writes; a separate Claude review session or the human product owner reviews. Ownership cannot be ambiguous within a task. (Until 2026-09-28 Codex and Claude shared these roles; records from that period are kept as written.)
 
 ## Handoff format
 
@@ -32,6 +32,6 @@ The reviewer must inspect the actual diff and tests. Do not provide the implemen
 
 ## Serial development
 
-Implementation is serial: one writer owns the working tree at a time, and both agents append completion and handoff records to `docs/development-log.md`. The current ownership map and delivery sequence are recorded in `docs/workstreams.md`.
+Implementation is serial: one writer owns the working tree at a time, and every session appends completion and handoff records to `docs/development-log.md`. The current ownership map and delivery sequence are recorded in `docs/workstreams.md`.
 
 Durable status, working prompts, and append-only bidirectional question/answer mailboxes are under `handoff/`. Mailbox messages clarify work but never override `AGENTS.md`, an acceptance task, an ADR, or the single-writer protocol.

docs/product.md

@@ -21,12 +21,11 @@ Within the permissions of the signed-in Gitea account, the application must supp
 - Browsing a repository tree at an explicit branch, tag, or commit.
 - Viewing text source with the selected ref and path always visible.
 - Viewing commit history and per-commit file changes.
-- Comparing branches and commits without implying write access.
 - Viewing pull requests, issues, reviews, comments, and notifications.
 
 Binary files, Git LFS pointers, submodules, and files too large for safe mobile rendering require an explicit fallback rather than being decoded as ordinary source text.
 
-The first release is read-oriented. Creating, merging, deleting, or administering resources is out of scope until explicitly approved.
+The first release is read-oriented. Creating, merging, deleting, or administering resources is out of scope until explicitly approved. The one approved write is starring and un-starring a repository for the favorites list, which is why sign-in requests the `write:user` and `write:repository` scopes (see ADR-004 and TASK-033).
 
 ## UX principles
 
@@ -52,6 +51,9 @@ The first release is read-oriented. Creating, merging, deleting, or administerin
 - Visual identity, icon, and color palette: sky blue + white, with the UbiSam wordmark small in the top-left of the root screen (see TASK-045)
 - Repositories are cached for offline browsing at the list level only (branches/files inside a repository are not cached); see TASK-044
 
+- Comparing branches and commits was removed from the history screen in TASK-024
+- The team mainly reads C# and C++; source viewing is tuned for those first (see TASK-049)
+
 ## Open product decisions
 
 - Whether biometric reauthentication is required