revamp markdown project files

1 files changed, 19 insertions, 76 deletions

diff --git a/ROADMAP.md b/ROADMAP.md
index c63853a..46af8dd 100644
--- a/ROADMAP.md
+++ b/ROADMAP.md
@@ -1,23 +1,5 @@
 # Hutch Roadmap
 
-## Positioning
-
-Hutch is already beyond a minimal v1. The core SourceHut surfaces are present:
-
-- Authentication with PAT flow
-- Git repositories
-- Mercurial repositories
-- Trackers and tickets
-- Builds
-- Sharing
-- Core settings and app metadata
-
-The main risk now is not lack of scope. The main risk is shipping too late with
-an increasingly broad surface area and not enough polish.
-
-This roadmap treats the current app as a real 1.0 candidate and shifts the
-focus from feature expansion to launch readiness.
-
 ## Version 1.0 Goal
 
 Ship a stable SourceHut mobile client with strong support for the most active
@@ -26,10 +8,12 @@ day-to-day workflows:
 - Browse and manage repositories
 - Browse and manage tickets
 - Browse and manage builds
-- Support both git and hg repositories
+- Support both Git and Mercurial repositories
 - Provide dependable sharing and navigation
 
-Version 1.0 does not need to cover every sr.ht service.
+Version 1.0 does not need to cover every SourceHut service.
+
+---
 
 ## Release Strategy
 
@@ -50,25 +34,25 @@ Focus on quality, not new surface area.
   - Build submission
 - Verify build retry and edit/resubmit flows
 - Verify repository sharing links for:
-  - repository
-  - commit
-  - file
+  - Repository
+  - Commit
+  - File
 - Verify sharing links for:
-  - build
-  - tracker
-  - ticket
-  - profile
+  - Build
+  - Tracker
+  - Ticket
+  - Profile
 - Review empty/loading/error states across all main tabs
 - Remove any leftover temporary debug logging
 - Audit device-only issues:
   - Xcode attach quirks
-  - on-device auth/cache behavior
+  - On-device auth/cache behavior
   - WebView rendering performance
 
 #### UI/UX polish checklist
 
 - Tighten wording and error messages across create/edit flows
-- Confirm summary tabs feel consistent across git and hg
+- Confirm summary tabs feel consistent across Git and Mercurial
 - Confirm toolbar actions are visible and non-duplicated
 - Confirm README rendering is smooth on large repositories
 - Confirm forms behave well on iPhone-sized screens
@@ -82,6 +66,8 @@ Focus on quality, not new surface area.
 - Finalize support URL / project URL
 - Decide whether TestFlight comes before public launch
 
+---
+
 ### Phase 2: Version 1.1
 
 Add one compact new service surface after launch.
@@ -99,6 +85,8 @@ Add one compact new service surface after launch.
 - paste.sr.ht is relatively self-contained
 - lists.sr.ht is valuable, but broader in UI and data model scope
 
+---
+
 ### Phase 3: Version 1.2+
 
 Expand only after the v1 core is stable in the wild.
@@ -106,50 +94,5 @@ Expand only after the v1 core is stable in the wild.
 - lists.sr.ht tab
 - paste.sr.ht creation/editing polish
 - pages.sr.ht management
-- broader deep-link/share coverage
-- workflow refinements for builds and tickets
-
-## What Counts As “Done Enough” For 1.0
-
-Hutch is ready for 1.0 when:
-
-- The main flows work reliably on real devices
-- Errors are understandable
-- The app does not feel inconsistent across git/hg/builds/tickets
-- The missing services feel like roadmap items, not broken gaps
-
-That means `lists.sr.ht`, `paste.sr.ht`, and `pages.sr.ht` are not blockers for
-the first release.
-
-## Non-Blockers For 1.0
-
-These should not delay launch:
-
-- Donation page / IAP
-- Broad service parity across all SourceHut products
-- Public repo discovery equivalent to `sr.ht/projects`
-- Advanced creation workflows beyond what the public APIs cleanly support
-
-## Open Product Questions
-
-These are worth deciding before or shortly after launch:
-
-- Should the app be positioned as “SourceHut client” or “SourceHut for git/hg,
-  tickets, and builds” in App Store messaging?
-- Should exact repository lookup live in Repositories search, a dedicated sheet,
-  or both?
-- Should `paste.sr.ht` or `lists.sr.ht` be the first new post-launch tab?
-- Is TestFlight feedback needed before calling the first public build 1.0?
-
-## Recommended Next Step
-
-Do not add another major service right away.
-
-Instead:
-
-1. Run a release-focused polish pass
-2. Build a strict 1.0 checklist from the current app
-3. Ship to TestFlight or release publicly
-4. Use `ROADMAP.md` and `TODO.md` separately:
-   - `ROADMAP.md` for release strategy
-   - `TODO.md` for concrete implementation backlog
+- Broader deep-link/share coverage
+- Workflow refinements for builds and tickets