refactor 3

docs/repo-state-plan.md

@@ -1,6 +1,6 @@
 # Repository state and panel flow plan
 
-Status: phases 1-2 implemented, phase 3 next (2026-09-13)
+Status: phases 1-3 implemented (2026-09-13)
 
 Builds on `docs/backend-rearchitecture.md`, especially §7 (notify audit),
 §11 (split independently-observed state), §12 (one debounce at the source)
@@ -281,27 +281,56 @@ Status: implemented.
 3. `open_repo_panel` and `RepoDetailView::new` take an address plus an optional
    hint, so a repository panel opens from a `RepoAddr` alone. This pulls the
    address-based constructor forward from Phase 3 step 2.
-4. `RepoDetailView::attach_store` adopts the store's first announcement when
-   `initial` is still empty and calls `load_repo`, so a panel opened by address
-   fills in instead of waiting for the caller to have the announcement.
+4. `RepoDetailView::attach_store` starts the explorer from the store's first
+   announcement when the panel was opened by address alone, so a panel opened
+   by address fills in instead of waiting for the caller to have the
+   announcement. Phase 3 moves this onto the single store observer, gated by
+   `repo_started`.
 5. `open_upstream`: the 60 x 250 ms poll and the `pending_upstream` field are
    gone. It opens the panel by address; the store's `subscribe_remote` fetches
    the announcement from the bootstrap relays and step 4 loads the explorer.
 
 ### Phase 3 - one entity for local and NIP-34
 
-1. `signed_state/src/repo.rs`: `addr`/`path` options, `new_local`,
-   `announce`, `Option<Subscription>`, action guards.
-2. `views/repo/mod.rs`: single `store` field; `new_local`; header,
-   display name, `load_repo`, `open_init_dialog` derive from the store. The
-   address-based `new` is already in place from Phase 2.
-3. `views/repo/store.rs`: always observe; `refresh_statuses` returns false
-   when not announced.
-4. `views/repo/actions.rs`, `header.rs`, `banners.rs`: drop
-   `Option<Entity<RepoStore>>` guards, guard on `addr()` instead.
+Status: implemented.
+
+1. `signed_state/src/repo.rs`: `addr: Option<RepoAddr>`,
+   `path: Option<PathBuf>`, `announcement: Option<Announcement>`,
+   `_subscription: Option<Subscription>`. `new(addr, hint, cx)` seeds the
+   announcement and relays from the hint; `new_local(path)`; `announce`
+   switches a local store to NIP-34 in place, keeping `path`. `addr()` returns
+   `Option<&RepoAddr>`; `refresh`/`connect_announced_relays`/`subscribe_remote`
+   no-op without an address. Nostr-side actions guard with `not_announced`
+   (unit actions) or `action_error` (task actions).
+2. `views/repo/mod.rs`: one `store: Entity<RepoStore>` field. `initial` and
+   `local_path` are deleted; `new_local` builds a local store. The store
+   observer starts the explorer once an announcement lands, tracked by
+   `repo_started`. `display_name`, `load_repo` and `open_init_dialog` derive
+   their mode from `addr()`/`path` instead of the removed fields.
+3. `views/repo/store.rs`: the store is observed from construction for both
+   modes; `apply_announcement` calls `store.announce` on the existing entity.
+   `refresh_ready_statuses` and `refresh_statuses` return early when `addr()`
+   is `None`.
+4. `views/repo/{actions,header,banners,loading}.rs`: the
+   `Option<Entity<RepoStore>>` guards are gone. Announced-only entry points
+   (issue/PR lists, new PR, send patch) guard on `addr()`; `NewPullRequestView`
+   and `PullRequestDetailView` thread the address option through their
+   prefill/binding paths.
 5. `LocalReposStore` stays as the scan index; `CheckoutsStore` stays the
    association authority.
 
+Deviations from the sketch above:
+
+- `path` is set only by `new_local` and kept by `announce`. `new` does not
+  resolve an associated checkout: the explorer still mirrors the cache for
+  announced repositories, so a stored checkout path would be dead weight.
+  The field is the seam for the open question below.
+- `new_local` takes no `Context`: a local store has nothing to subscribe to and
+  no first pass to defer.
+- `new` keeps the open-time hint until the first pass has confirmed what the
+  database holds, so a panel opened from a hint renders before the query lands
+  and still adopts a later deletion.
+
 ### Phase 4 - deferred, only if duplicate stores become a problem
 
 One store per address via `HashMap<RepoAddr, WeakEntity<RepoStore>>` inside