Drop redundant "Feed" button on the logged-in home page

The navbar already has a "Feed" entry that signed-in users see on every
page, including /. The page-header button next to "New Activity"
duplicated that path without adding anything — they pointed at the same
URL, with the navbar entry being the more discoverable of the two.

Stream D from docs/information-architecture.md.

- apps/journal/app/routes/home.tsx — remove the Feed anchor; "New
  Activity" stays as the only header CTA on the personal dashboard.
- openspec/specs/journal-landing/spec.md — retire the "Social feed
  link for signed-in users" requirement that prescribed the now-deleted
  button.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Ullrich Schäfer 2026-04-26 08:44:08 +02:00
parent 34f40d6744
commit 11635eaead
2 changed files with 6 additions and 26 deletions

View file

@ -53,18 +53,6 @@ For signed-in users, the home page SHALL render a personal activity dashboard: a
- **WHEN** a signed-in user has no activities yet
- **THEN** the dashboard shows an empty-state message pointing to activity creation, while the welcome line and New Activity CTA remain visible
### Requirement: Social feed link for signed-in users
For signed-in users, the personal dashboard SHALL include a prominent link to the social feed at `/feed` (see `social-follows` spec, "Social activity feed") alongside the existing "New Activity" CTA. The link SHALL be visible regardless of whether the user follows anyone yet — the social feed's own empty state handles the zero-follows case.
#### Scenario: Feed link on personal dashboard
- **WHEN** a signed-in user loads `/`
- **THEN** the dashboard header shows a "Feed" (or equivalent) link to `/feed` next to the "New Activity" CTA
#### Scenario: Feed link is not shown to signed-out visitors
- **WHEN** an unauthenticated visitor loads `/`
- **THEN** the visitor-home layout does not expose a link to `/feed` (the route requires authentication)
### Requirement: Notifications entry in the navbar
The navbar SHALL render a single inbox entry — a bell icon — for signed-in users, linking to `/notifications`. It SHALL render an unread count badge when the user has at least one unread notification, and no badge when the count is zero. The badge live-updates via `sse-broker`; the loader-driven count is the SSR baseline. Follow-request actions (Approve / Reject) live as the Requests tab inside `/notifications` (see `notifications` spec); the navbar SHALL NOT render a separate "Follow requests" entry — the bell is the single inbox surface.