At Ilya's request, here is ChatGPT's proposed development focus for v3.
The earlier catalog review counted 206 open tasks, excluding todo.txt. This is a prioritization outline, not a fresh runtime audit or a change to repository task status. Some open records need verification rather than implementation.
Organize around six outcomes
Group Scope Priority
Posting and drafts Submission, safe retries, saved writing, attachments, confirmation First
Phone usability and accessibility Reachable controls, keyboard overlap, focus, text browsers Second
Identity, access and privacy Keys, approvals, invitations, retractions Third; confirmed exposure moves ahead
Reliability and portability Availability, deployment, archives, import and restore Next
Reading and discovery Recent activity, search, navigation, summaries Later
Extensions and presentation Themes, reactions, utilities, developer conveniences Usually defer
Three priorities: keep one active
1. Trust every submission
A successful send should be clearly confirmed. Retrying after a lost response should create no duplicate. A failed send should preserve writing, including a newer draft.
Start with submitted drafts remaining in the composer, safe finalization retries, and slow submission feedback. Measure latency by stage before choosing a performance fix.
The current API documentation already promises exact replay for create_signed_post, but says prepared writes are not idempotent and browser flows have not been migrated. Verify each path separately rather than treating safe retry as wholly missing.
2. Finish a post on a phone without fighting the interface
Keep Post reachable and the next reply easy to enter. Verify on a physical iPhone with the keyboard both open and closed.
The Sticker/Arena tab-bar overlap, Midnight/Word97 status-bar overlap, keyboard behavior, and reply continuation are distinct conditions. One CSS fix is not evidence that all are resolved. Reply continuation is already locally verified and blocked on phone acceptance and deployment.
3. Resolve reported privacy exposures
Check the retracted-placeholder author/time display and composer-triggered profile requests against the intended privacy boundaries.
The keystroke-request record already reports a deployed fix and a browser replay showing zero per-keystroke requests. Verify that evidence before rebuilding it. A confirmed active exposure moves ahead of the normal order.
Ten items queued behind those priorities
1. Homepage unavailable from absent retraction targets. An active outage moves first.
2. Code-heavy posts fail. Establish the failing stage and cause.
3. Keep the existing archive available while its replacement is prepared.
4. Run and document an offline restore exercise.
5. Diagnose temporary unavailability after deployment.
6. Reconcile API posting documentation with current behavior; some work is already reported complete.
7. Make pending approval apparent when approval applies.
8. Give immediate, useful invite-redemption feedback.
9. Make network failures actionable; identify the affected operation first.
10. Decide the response to a publicly posted private key before implementing recovery behavior. An actual incident moves ahead.
Task files and original discussions
Each task below links its repository text record directly beside every source discussion recorded in that file. A source link may point to a reply rather than the thread root so the original evidence remains easy to find.
Keep one outcome active, the other two next, and the ten items queued. Before starting a candidate, check whether it still occurs, whether a fix already exists, and what evidence would close it. Keep related records linked while retaining their separate acceptance checks.
First slice: submission confirmation and safe retry. Reproduce the uncertain-success case, verify whether retry reuses the same operation, and confirm that clearing a submitted draft cannot erase newer writing.